Trac #728 Delaunay triangulation performance problem

[dbaston]

As described in postgis/postgis#73

[strk]

interesting enough, there's no testcase triggering a call to that removal method!

[strk]

Taking it back, the method is called. From the testsuite only once and finds 12 edges.
Better review how many such calls the class may get. To run (and improve) the test:
./geos_unit geos::triangulate::Delaunay

Reviewing internal usage of that container would be another approach, as I'm pretty sure .size() is being called far more than needed.

[dbaston]

From looking on the JTS side, I don't think QuadEdgeSubdivision::remove method is ever called from within the library - it would only ever be accessed if a user is manipulating their own QuadEdgeSubdivision, which would be a fringe use case. Even the comments in JTS (which were copied to GEOS) indicate the performance of the remove method is unimportant:

https://github.com/metteo/jts/blob/master/jts-core/src/main/java/com/vividsolutions/jts/triangulate/quadedge/QuadEdgeSubdivision.java#L230

I think switching the container type is a simple solution that will bring a 10x - 100x performance increase for the core use cases of GEOSDelaunayTriangles and GEOSVoronoiDiagram. It also better matches the JTS implementation, which uses an ArrayList instead of a LinkedList.

[strk]

Agreed, committed as r4119 = 80a475a (dunno how to close this PR via mail reply)

[dbaston]

Thanks! Can this be applied to the 3.5 branch? It would be nice to get the benefit for ST_Voronoi in PostGIS.

[strk]

r4120 = 1287c9d (refs/remotes/3.5)