Alignments layout code slow under MainThreadRpcDriver

[cmdcolin]

The change to make the granular rect layout from a map to an observablemap appears to maybe have taken a toll on making the alignments track slow. This would also affect other types of feature tracks

Each addRect in the embedded version can take ~70ms and having a modest number of features can result in a lot of slowness

Related to #1790

I think this is basically separate from the general alignments performance issue #969 so I made a new issue here

Noticed and mentioned earlier in a demo @garrettjstevens made https://garrettjstevens.github.io/jbrowse-react-linear-genome-view-demo/ can be seen there

Note that the webworker version takes about 0.93 ms for a single addRect so about 70x faster

[cmdcolin]

one idea could be to use a transaction() from mobx to try to avoid reaction logic during these many adds
this seems a little but awkward and would have to be done in multiple places that use addRect, but may help
otherwise, we may have to consider whether there is an alternative to observablemap

[garrettjstevens]

Is this addRect in PrecomputedLayout on the JBrowse Web webworker vs. addRect in the GranularRectLayout?

[cmdcolin]

Both refer to GranularRectLayout addRect from what I can tell, the screenshots both have an entry of addRect selected in the profiler results referring the GranularRectLayout file

[garrettjstevens]

That's odd, because it's observable in both places. I'm not sure why it would be so different in MainThreadRendering.

[cmdcolin]

In the mainthread, there may be a thing actually actively observing it, but in the webworker, probably not

[cmdcolin]

Note that PrecomputedLayout is basically what is used on the mainthread to "hydrate" the serialized layout that the webworker sends over

[garrettjstevens]

I can also reproduce this in JBrowse Web using the MainThreadRpcDriver. Using the below track config at location 13:32,315,061..32,400,241 under normal JBrowse Web, the track loads in ~15-20 seconds. If you change the configuration to use MainThreadRpcDriver, though, the track does not successfully load and the page ends up non-responsive.

Use main thread RPC with this configuration:

"configuration": {
  "rpc": {
    "defaultDriver": "MainThreadRpcDriver"
  }
}

Track config is:

{
  "type": "AlignmentsTrack",
  "trackId": "NA12878.alt_bwamem_GRCh38DH.20150826.CEU.exome",
  "name": "NA12878 Exome",
  "assemblyNames": [
    "GRCh38"
  ],
  "category": [
    "1000 Genomes",
    "Alignments"
  ],
  "adapter": {
    "type": "CramAdapter",
    "cramLocation": {
      "uri": "https://s3.amazonaws.com/jbrowse.org/genomes/GRCh38/alignments/NA12878/NA12878.alt_bwamem_GRCh38DH.20150826.CEU.exome.cram"
    },
    "craiLocation": {
      "uri": "https://s3.amazonaws.com/jbrowse.org/genomes/GRCh38/alignments/NA12878/NA12878.alt_bwamem_GRCh38DH.20150826.CEU.exome.cram.crai"
    },
    "sequenceAdapter": {
      "type": "BgzipFastaAdapter",
      "fastaLocation": {
        "uri": "https://ftp.ensembl.org/pub/release-100/fasta/homo_sapiens/dna_index/Homo_sapiens.GRCh38.dna.toplevel.fa.gz"
      },
      "faiLocation": {
        "uri": "https://ftp.ensembl.org/pub/release-100/fasta/homo_sapiens/dna_index/Homo_sapiens.GRCh38.dna.toplevel.fa.gz.fai"
      },
      "gziLocation": {
        "uri": "https://ftp.ensembl.org/pub/release-100/fasta/homo_sapiens/dna_index/Homo_sapiens.GRCh38.dna.toplevel.fa.gz.gzi"
      }
    }
  }
} 

[cmdcolin]

yep it's not really particular to the embedded component, more the mainthreadrpc. the embedded component is just a common use of mainthreadrpc.

[cmdcolin]

technically it is not even alignments either, any usage of the granularrectlayout would cause this with mainthreadrpcdriver