You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the flame charts, we observe three main bottlenecks:
Redrawing over and over
Data transformations - converting a data into a form that that makes it ready to visualize. This involves use of
Creating GoslingTrackModel over over again
Reduce redrawing
Redrawing everything to the same Graphics object is expensive. There are several strategies to overcome this
Stretch the Graphics object everything is drawn to. This was implemented in perf(core): stretch certain marks instead of redraw #1018. However, this strategy does not work well for shapes that do not have right angle corners, since only the x-direction gets stretched.
Draw everything as a Sprite and translate the Sprites on zoom. Compared to redrawing at every frame, translating Sprites is much more performant according to my testing.
Initialize GoslingTrackModel only when needed
GoslingTrackModels are reinitialized every time draw() is called. However, it only changes when the data, spec, or theme changes. We need to persist the models unless the data, spec, or theme changes.
The text was updated successfully, but these errors were encountered:
Looking up values using encodedPIXIvalues is expensive -> instead look up once and cache the results in GoslingTrackModel
Similarly, create UUIDs for each data point once and store with the data in GoslingTrackModel
Access the scale in the tile directly
How does draw time scale with the number of tracks?
Theoretically, it should take 1.3 ms to draw each track. Does draw time scale linearly with the number of tracks? Yes, but not with the relation that we want. Specifically, it draws 2x-1 times more than it needs to.
For example, here a visualization with 3 tracks. We expect each track to be drawn only once (3 total calls to draw) but instead we see 5.
Overall, this amounts in the following relationship:
The frame-rate of certain Gosling visualizations is very low when zooming and panning. What are the main bottlenecks?
Flame charts
We can interact with laggy visualzations and observe their flame charts to understand what is causing poor performance.
Multiple Sequence Alignment
Here's a flame graph when zooming in and out of :
SARS-Cov2
Corces et al.
Mark Displacement
Observations
Based on the flame charts, we observe three main bottlenecks:
Reduce redrawing
Redrawing everything to the same Graphics object is expensive. There are several strategies to overcome this
Initialize GoslingTrackModel only when needed
GoslingTrackModels are reinitialized every time
draw()
is called. However, it only changes when the data, spec, or theme changes. We need to persist the models unless the data, spec, or theme changes.The text was updated successfully, but these errors were encountered: