Don’t reassign listener methods? about d3-geo HOT 7 OPEN

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.

from d3-geo.

Any thoughts on this? It sounds like it could be a pretty clear win.

from d3-geo.

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. 😄

from d3-geo.

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.

from d3-geo.

You've mentioned the composable graphics pipeline a couple times, any idea when you might want to start work on it?

from d3-geo.

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

from d3-geo.

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?

from d3-geo.