Layer merging performance

[Don-vip]

The "merge layer" action can be slow as hell. With these two data sets, including only new primitives:

• A: 30.000 highways, 80.000 nodes, 9.000 relations associatedStreet
• B: 65.000 addr:housenumber

The loading of each data set takes only few seconds. However if I try to merge them, I'm forced to cancel the operation after several minutes of processing without any visual indication of the remaining time.

Two things to do here:

• Speed up the process, it shouldn't take so long (I have added some traces to measure performances, JOSM merges nodes at the incredible speed of 40 nodes per second !)
• Indicate in a progress bar the advancement (currently, there is no progress bar at all)

[Don-vip]

patch awaiting end of stabilization phase

[Don-vip]

The merging speed bumped in my examples from 40 to 300 nodes per second just by:

• using a XOR in OsmPrimitive.hasEqualSemanticAttributes()
• checking if arrays are null or of the same size before creating and comparing the key maps in AbstractPrimitive.hasSameTags()
• looping on initial target layer primitives instead of current target layer primitives (there's no sensr to check for current primitives as they include primitives we have already merged from the source, right ?)

[Don-vip]

In [4684/josm]:

see #7159 - Layer merging performance

[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]

Nice!

[taylor.smock]

I'm taking a quick look through other methods in LatLon right now as well, looking for stuff that can/should be moved to ILatLon. I would not be surprised if some of them are being used like so node.getCoor().greatCircleDistance(otherNode.getCoor()).
looks at Geometry#getDistance, Geometry#getDistanceSegmentSegment (my fault)

Current candidates (I'll open a separate ticket for this):

• greatCircleDistance
• bearing
• interpolate (maybe -- sticking point is the return value, I'd want to see how it was being used)
• getCenter (see above)

EDIT: Ticket opened (#22115).