Slowdown due to superficious DOM modifications

[d3]

Slowdown due to superficious DOM modifications

[mbostock]

None of those modifications are superfluous in the general case. Various changes to the axis configuration can require those updates:

• The axis tick size can change.
• The axis orientation can change.
• A prior axis transition can be interrupted, preventing the tick opacity from reaching 1.

(You also removed a few essential features of the axis, like a default appearance and cross-fading ticks during a transition.)

You could move a few things to entering elements if you require that the axis orientation doesn’t change. But then you’d have to document that the way to change the axis orientation is to remove the old axis and add a new axis, rather than just re-applying a new axis with the new orientation.

You could avoid setting the entering line’s x2 and entering tick’s x attributes in the case that you’re updating the axis instantaneously (since they are subsequently set on enter + update), but this is a relatively minor optimization.

You could avoid setting a few attributes separately on each tick, but it would require restructuring the axis so that the tick labels and tick lines are grouped separately, rather than grouping the label and line for each tick together. Which would mean you’d need to set the transform attribute on twice as many elements to move the ticks into place, or using attributes to position the tick labels and lines rather than transforms.

I could maybe see changing the axis to assume a fixed orientation; see e1d90ce. (I also changed it to only define default styles the first time the axis is applied.) I am sure it will trip up at least some users in the future, but maybe that’s acceptable if documented. I could also maybe see the axis detecting an orientation change and patching the difference just in that case, though I fear that adds complexity to the implementation…

[mbostock]

I’ve merged the aforementioned optimizations and documented the requirement that the axis orientation is fixed. If you have other suggested optimizations, please let me know. Thank you.

[nponeccop]

Can you update http://bl.ocks.org/mbostock/db6b4335bf1662b413e7968910104f0f to use alpha 50, as it incorporates the above performance improvements?

Wrapping draw calls with d3.timeout to avoid multiple updates per frame improves framerate in that example too, but makes code bulky and less suitable for learning. But you could add a note to the block's readme.

[mbostock]

I updated it.