[PATCH] Decrease allocations/CPU samples in Geometry.getDistanceSegmentSegment

[taylor.smock]

Current statistics, using Mesa County, CO as the data ("nwr in 'Mesa County, CO'") with the MapWithAI plugin validations enabled:

• CPU samples: 54,604 -> 39,146 (-15,458, -28.3%)
• Memory allocations: 170,983,028,400 -> 4,645,539,624 (-166,337,488,776, -97.3%)
  • All remaining allocations are from creating a new LatLon during interpolation
• .7% improvement in GC threads (overall, see notes)

Notes:

• getDistanceWayNode was also modified to avoid EastNorth allocations
• All remaining allocations come from the creation of new LatLon objects. This may be alleviated when value classes become a thing in Java LTS.
• Profiling was done from application startup to shutdown

[taylor.smock]

In 18589/josm:

Fix #22453: Decrease allocations/CPU samples in Geometry.getDistanceSegmentSegment

Statistics, using Mesa County, CO as the data ("nwr in 'Mesa County, CO'") with
the MapWithAI plugin validations enabled (validation run):

• CPU samples: 54,604 -> 39,146 (-15,458, -28.3%)
• Memory allocations: 170,983,028,400 -> 4,645,539,624 (-166,337,488,776, -97.3%)
  • All remaining allocations are from creating a new LatLon during interpolation.
• .7% improvement in GC threads (overall, see notes).

Notes:

• getDistanceWayNode was also modified to avoid EastNorth allocations.
• All remaining allocations come from the creation of new LatLon objects. This may be alleviated when value classes become a thing in Java LTS, and we start using them.
• Profiling was done from application startup to shut down.

[taylor.smock]

In 18590/josm:

See #22453: Decrease allocations/CPU samples in Geometry.getDistanceSegmentSegment

This mostly reverts r18589, as it changed the distances returned to LatLon space,
which caused tests to fail.

[taylor.smock]

Milestone renamed