Paul Ramsey
Paul Ramsey
I don't have a voronoi test yet, but my [performance suite](https://github.com/pramsey/geos-performance) shows no differences, with one exception: the prepared point-in-poly test seems to be consistently about 10% faster.
I hooked a Delaunay build into my test harness but couldn't measure any different between this PR and 3.13.
Thanks for the nice writeup of your perf_* results. I did the same tests on my MacBook Pro and I'm afraid I see no consistent advantage for this particular optimization....
Would it make sense to gate this behind something like ``` #if defined(__x86_64__) || defined(__x86_64) || defined(__amd64__) || defined(__amd64) || defined(_M_X64) || defined(_M_AMD64) # define ARCHITECTURE_X86_64 ```
OK, I'm convinced. Could you throw some commentary into the patch with the references you are using and maybe a brief description. The magic constant in particular needs a reference....
Is there any implementation improvement left to wring out of kd-tree? The "conventional wisdom" on kd-tree is that for points it should be superior to r-tree in principle. If it's...
I think you proved the point: it's faster, it's not worse. Why not merge?
I am surprised you are seeing missing Z's in clipping, as the constructive geometry overlay engine does try to in-fill the new points with interpolated Z. Which gives you a...
Not really... the only reason this works is because the external buffer is exactly the same shape as the internal buffer.
Can we mostly start reading CoordinateXY by reference instead?