Giters

d3 / d3-delaunay

Compute the Voronoi diagram of a set of two-dimensional points.

Home Page:https://d3js.org/d3-delaunay

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Severe performance regression with delaunay.find since v4.1.0

mourner opened this issue · comments

commented

@mbostock I just tried upgrading https://observablehq.com/@mbostock/voronoi-stippling to newer versions of d3-delaunay and discovered that it gets really slow since v4.1.0 (but is fast with v4.0.2) — apparently abb0fd8 caused a severe regression of delaunay.find performance (profiling shows it taking most of the worker time). I wonder what's going on here. Could the way we use a generator cause this? cc @Fil

commented

Damn, if I change neighbors to be a regular function that returns an array (rather than a generator), it gets much faster, so it is indeed caused by using a generator unfortunately. I've added a bench script to explore this in 02dfd85

Results (10 iterations, total time):

  • v4.0.2: 1572ms
  • v5.1.0: 6177ms
  • v5.1.0 + neighbors returning array: 2145ms

Since find is a building block of many algorithms and is often on a hot path, I would suggest rewriting _step to inline iteration over neighbors (avoiding both a generator and allocating neighbor arrays), even if this means duplicating code.

But generally, I think we might want to get rid of generators in the library and release a new major version — performance concerns overweight generator convenience in algorithmic libraries like this IMO. As a side benefit, this would make it ES5-compatible.

commented

tbh I don't see a speed difference in any browser (tested with Safari, FF and Chrome on MacOS):
https://observablehq.com/d/a14108eadf908ea4

my mistake — indeed there is a 4x difference.

commented

I tested it out on the stippling notebook — works fast now with v5.1.1 https://observablehq.com/d/16e9be3e70ccefe5