Don’t reassign listener methods?
I wonder if it would be faster to not reassign listener methods, since I expect that dynamically assigning methods makes it harder for the runtime to optimize.
So I took about an hour and threw together a benchmark that pits d3.geo.length against an "optimized" version of length that doesn't reassign listener methods.
http://bl.ocks.org/chrisuehlinger/5ab433e12fbfa6c7d9b87be1a0c7e6f7
In Chrome I saw speedups ranging from 1.5x to 2.1x. In Mac Safari the gains were much smaller, 0.98x-1.15x. In Firefox it was about 1.1x-1.3x.
Any thoughts on this? It sounds like it could be a pretty clear win.
I’ve for this assuming that it tests well in real-world usage (like rendering a rotating orthographic projection). But it’s also a fair amount of work (given the complexity of clipping), and it might be a better long-term strategy to start work on a new composable graphics pipeline.
That said I’ve not started work on that, either… So if you want to take a crack at an optimization I see no harm in it. 😄
Related, it seems that string concatenation (string +=) is now faster than array.join, so perhaps PathString should be reimplemented. See also d3/d3-path#9.
You've mentioned the composable graphics pipeline a couple times, any idea when you might want to start work on it?
I started back in mid 2014 but I haven’t had time to work on it since. 😦 Here are two examples:
https://bl.ocks.org/mbostock/e2a20d86124693ef0f93 https://bl.ocks.org/mbostock/e48a00d4db5c3b042145
I recall that there was a branch on the old D3 repo (https://github.com/d3/d3/tree/graphics-pipeline) which was moving in this direction. Do you think it would be valuable to try and manually "rebase" this branch into d3-geo to see what kinds of questions it raises?
Also, should we make a new issue to keep track of this project?