r6-operator-counters
r6-operator-counters copied to clipboard
BurkusCat
Performance improvements [HIGH PRIORITY]
- The app can feel a bit sluggish when zoomed out
- Optimise performance of the app
- Potentially contribute back to neo4dj3 if any optimisations apply there
Pretty pleased with these results: https://www.webpagetest.org/result/181228_TB_7e9ae122f72f92ec5d7ce0ddc1cd45c9/ Any ideas of places to improve from that? A few of the .svgs weren't cached in that test run and the .svgs took a long time before they started downloading.
Performance in this graph is really good and it is similar to this repo's graph https://bl.ocks.org/almsuarez/4333a12d2531d6c1f6f22b74f2c57102
Added the branch performance-fix with a possible temporary patch. There is not a ton of information about how to manipulate or use canvas with d3. Another option I considered was a library change from neo4jd3 to WebGL or similar, but I would like to exhaust all options first.
Let me know your thoughts.
Sorry, completely missed this comment @CrayCrayDecay !
I really love this temporary change. It makes the app feel a lot snappier. I do like the never ending physics currently on the site, but the low framerate makes it feel bad. Maybe if we find other improvements we can go back to it sometime.
Definitely PR that change in :)
Observation: framerate increases the more you zoom in. Is it related to the rendering of .svgs?
However, tick relationship text and tick relationship outlines take way too long to compute, is it related to the the processing of the physics/positions of the .svgs?
Commenting out tickRelationshipOutlines(); I thought would improve things but it still appears to take a long time drawing. Maybe physics + rendering are both bottlenecks?
#209 should dramatically reduce performance issues by reducing the number/length of "forced redraws". After this, the main bottlenecks will be:
- The complexity of the calculations used in transforms. Can there be code optimisations here or faster estimates?
- The length of the recalculate style + layout operations (these now only happen after the processing). They take quite a few ms, can anything be optimised to reduce their duration?