[PATCH] Improve speed of selecting large amounts of objects

[Nzara]

If you accidentally press Ctrl-A (Select All) after having downloaded a large data set, the system may become unresponsive for a several minutes. This gives you an involuntary coffee break.

A way to cancel a long running operation would be helpful.

[taylor.smock]

Replying to Nzara:

If you accidentally press Ctrl-A (Select All) after having downloaded a large data set, the system may become unresponsive for a several minutes. This gives you an involuntary coffee break.

A way to cancel a long running operation would be helpful.

It might be more useful for us to profile the code path and fix that instead.

For this specific case, it looks like it is mostly due to PrimitiveRenderer.getListCellRendererComponent.

Almost all the non-JVM CPU cycles are taken up inside that method by formatting code.
Almost all the memory allocations are done by PrimitiveRenderer.getListCellRendererComponent. The memory allocations are particularly bad (getListCellRendererComponent takes ~8 GB of allocations for Mesa County, Colorado (my "large" test file)).

With that said, doing the same thing multiple times will result in various optimizations from the JVM (this can be really significant; 50s to 30s as an example).

For all I know, it might be doing one of the "easy" optimizations already after the first run.

[taylor.smock]

Notes on the patch:

• Avoid Stream allocations in ConflictCollection.hasConflictForMy by only looking for a conflict if conflicts exist
• Avoid many string instantiations in DefaultNameFormatter by using cached properties
• Avoid some Stream allocations by using standard for loops in DefaultNameFormatter
• Use "" to get the component in PrimitiveRenderer.getListCellRendererComponent -- this reduced the memory allocations by ~50% by itself, and appears to have no side-effects. We should ask users on different systems with different UI systems if it works properly.
• Significantly reduce cost of Way.hasOnlyLocatableNodes by using a standard for loop instead of a stream -- this isn't as important for this ticket, but was found while profiling.

[taylor.smock]

In 18794/josm:

Fix #23085: Improve speed of selecting large amounts of objects

• JVM CPU usage was down ~50%, EDT CPU usage was down ~25%. EDT memory usage was down
• Avoid Stream allocations in ConflictCollection.hasConflictForMy by only looking for a conflict if conflicts exist
• Avoid many string instantiations in DefaultNameFormatter by using cached properties. This significantly reduces memory allocations CPU usage for DefaultNameFormatter methods.
• Avoid some Stream allocations by using standard for loops in DefaultNameFormatter
• Use "" to get the component in PrimitiveRenderer.getListCellRendererComponent -- this reduced the memory allocations by ~50% and CPU usage by ~70% for getListCellRendererComponent by itself, and appears to have no side-effects. We should ask users on different systems with different UI systems if it works properly.
• Significantly reduce cost of Way.hasOnlyLocatableNodes by using a standard for loop instead of a stream -- this isn't as important for this ticket, but was found while profiling. This makes that method have no effective memory allocations and reduces the CPU usage by ~90%.