From: Colin <col...@gm...> - 2021-11-22 20:18:07
|
One common reason for slowness is if you have features that cover the entire chromosome for gff3 The mechanisms of the gff3tabix make it try to resolve all the child features of large parent features, but if it's e.g. a "region" feature (col 3 says region) that covers the entirety of chr1, then jbrowse doesn't need to resolve the child features for that object. By default, region, chromosome, and contig type gff3 features don't perform this, but if you have a different type of gff3 feature that covers the entirety of of your chromosomes, then maybe you can either rename that type to "region" or add to the "dontRedispatch" config slot on the Gff3TabixAdapter -Colin On Mon, Nov 22, 2021 at 2:33 PM Ke Jiang <bio...@gm...> wrote: > Hi, > > I've been playing with JBrowse2 for a while. Recently I noticed that GFF3 > files, while following the instructions of gt sorting, bgzipping, and tabix > indexing, still load very slowly on JBrowse2 even for a very small genomic > interval. An interval as small as 100bp could take up to 5min to load. This > seems to only happen to those genome-wide GFF3 files such as genome > annotations and GFFs from StringTie or TopHat pipelines. A BED file with a > few entries loads very fast when zipped and indexed. BAMs/BigWigs also load > pretty fast. Does anyone also have this problem or notice similar behaviors > of large GFF3 files? All files are not stored locally on the JBrowse2 > server but stay in an S3 bucket on another server, if this information > helps. > > Thanks! > > Ke > _______________________________________________ > Gmod-ajax mailing list > Gmo...@li... > https://lists.sourceforge.net/lists/listinfo/gmod-ajax > |