GeometrySnapper runtime dominated by slow hypot().

[micycle1]

PR #923 replaced replaced Math.sqrt(x^2+y^2) calls with Math.hypot(x,y).

However this is a huge problem for things like the GeometrySnapper that call Coordinate.distance() repeatedly.

For instance, Geometry snapper is spending 83% of its runtime in hypot() (on goem with 4k points), which is unacceptable.

[dr-jts]

Do you have a comparison with using Math.sqrt(dx*dx + dy * dy)? That's required as a baseline to see the actual increase in time for hypot.

I'm fine with reverting the hypot change, either everywhere or in performance-critical places. But it would be good to have metrics that confirm the issue.

[micycle1]

Just pulled the code, and swapped out the hypot call.
Performance is roughly double.
Bit hard to capture exactly in profiling since it's so call-heavy and instrumentation distorts it (was profiling before).

[dr-jts]

Good enough for me. I will look into reverting that PR.

[dr-jts]

It's not surprising that Math.hypot is so much slower - it's doing a lot more work (see code here).

I am thinking about creating a MathUtil.hypot function which is a wrapper over Math.sqrt(x^2+y^2), to modularize the code and make it more self-documenting. This could be used everywhere, or unwrapped in performance-critical areas (although I'm guessing that the JIT will make the performance pretty good.