[PATCH] Significantly reduce allocations in DataSetMerger when merging nodes

[taylor.smock]

When I was profiling the MapWithAI plugin, I noticed that DataSetMerger#merge used ~400 MiB worth of allocations. With the attached patch, it uses ~19 MiB worth of allocations.

Steps to reproduce:

1. osm-download.bounds=39.0635486;-108.5716152;39.0708789;-108.5593414
2. Enable City of Grand Junction, CO, Esri Community Trees, Esri Roads Sample (Preview), MapWithAI, Statewide Aggregate Addresses in Colorado 2019 (Public), and United States Addresses.
3. Start profiling and download data + mapwithai data.

[taylor.smock]

Related ticket: #7159

[taylor.smock]

In 18464/josm:

Extract equalsEpsilon from LatLon into ILatLon

This significantly reduces allocations from DataSetMerger#merge.
In testing, it went from ~400 MiB allocations to ~19 MiB allocations.

The allocations largely came from checking if two nodes had equal coordinates.
The code used LatLon#getCoor followed by equalsEpsilon, when all the
required information was already present in Node, but LatLon had the method.

As an additional enhancement, equalsEpsilon was somewhat generified, in that
there is an additional method where we can specify a different precision.

This fixes #22104, see #7159.

[Don-vip]

In 18489/josm:

see #22104 - fix deprecation warnings

[taylor.smock]

Replying to Don-vip:

In 18489/josm:

see #22104 - fix deprecation warnings

Fair enough. I hadn't done that since it would have automatically been fixed when/if we dropped the code in LatLon. I suppose I also could have cast the variables to ILatLon as well.

[Don-vip]

In 35975/osm:

see #22104 - fix deprecation warnings

[Don-vip]

Replying to taylor.smock:

Fair enough. I hadn't done that since it would have automatically been fixed when/if we dropped the code in LatLon. I suppose I also could have cast the variables to ILatLon as well.

I hesitated as well to remove the method immediately. But the code being there for a long time, it's safer to keep it deprecated for plugins we don't control.

[taylor.smock]

Replying to Don-vip:

I hesitated as well to remove the method immediately. But the code being there for a long time, it's safer to keep it deprecated for plugins we don't control.

That is one of the reasons why I marked it as deprecated, instead of removing it. The hard part is that it shadows/overrides the ILatLon method without casting the second argument to an ILatLon (I don't believe the Java compiler is smart enough to understand LatLon#equalsEpsilon is deprecated, so it should use ILatLon#equalsEpsilon instead). So at some point, when we do decide to remove the method, we're going to have breakage.

With that being said, I do have a GitLab CI job I can use to find plugins where it will cause breakage.

[taylor.smock]

Replying to Don-vip:

In 35975/osm:

see #22104 - fix deprecation warnings

Sorry, I missed this.

I was going to update the plugins after the next tested release. Mostly because I was going to try and do the changes for #22115 at the same time.

Anyway, I'll go ahead and do the changes that I intended to do for this ticket now, so I don't miss them (specifically, Node#getCoor#equalsEpsilon -> Node#equalsEpsilon).

[taylor.smock]

In 35976/osm:

see #22104: Remove usages of Node#getCoor where possible

This also accounts for cases where Node has the methods used later,
so a new LatLon is unnecessary.

[taylor.smock]

In 35977/osm:

see #22104 (dist): Remove usages of Node#getCoor where possible

This also accounts for cases where Node has the methods used later,
so a new LatLon is unnecessary.