Precision diet

[rleir]

Description of proposed changes

What is the goal of this pull request? What does this pull request change?
Hi James @jameshadfield
This is an experimental PR, for discussion. Thanks -- Rick

It reduces the precision of cx and cy attributes as Trevor suggested.
The xTip and yTip are full precision Javascript floats
but when stored in the DOM in decimal text format
they bloat the DOM and decimal-to-hex takes longer (maybe d3 optimizes this already?).
This only matters when the number of tips is in 4 figures.
So, need to do a Math.floor() on cx and cy!
Please test this on a Macbook, Apple does tricks with resolution!

Related issue(s)

Fixes #
Related to #955 Perfomance Audit
and PR #1128

Testing

What steps should be taken to test the changes you've proposed?
If you added or changed behavior in the codebase, did you update the tests, or do you need help with this?
To test this, right click over a tip and inspect the css for the circle.
To Do: some performance tests on data sets with large numbers of tips. Google talks of RAIL testing, does that apply here (maybe just a bit?).

Maybe to test we could zoom a single step and time it to repaint? I am getting times over a second.
Another test: memory usage (shift-esc).

Thank you for contributing to Nextstrain!

[rleir]

I will investigate the integration test. Visually, this seems to be ok.
Next issue: something similar for paths.

[jameshadfield]

Hi @rleir -- can you detail how you're testing the memory footprint reductions via this PR? Looking in firefox dev tools (for the zika dataset), the circle DOM elements only take up ~4/250Mb of the memory.

Some ad-hoc performance tests zooming into a subclade of a large tree indicate that this PR might make things faster, but it would be nice to automate such testing.

P.S. This PR looks visually fine on MacOS & the integration tests failures are potentially unrelated to this PR.

[rleir]

Hi James
Yes, performance testing.. what I did so far was 'stopwatch timing'. We can do better than that, possibly by using Selenium. I will look into it.
Cheers -- Rick

[rleir]

@jameshadfield James:
"the circle DOM elements only take up ~4/250Mb of the memory." Most of the DOM is relatively static, but the tip and branch elements get rewritten frequently as you click on clades or change the date controls. I am not a d3 expert but I think that this storage needs to be particularly compact.

Even so, there are probably bigger performance gains to be made elsewhere in the code. Let's not dwell on this.
cheers -- Rick

[jameshadfield]

It may well be important & is a pretty simple fix it does improve things (even marginally). Closing this particular PR as the commits are included in #1142