[patch WIP] Join overlapping Areas is slow when combining many complex ways

[GerdP]

Load sample file join.osm.bz2 from #9911, select all elements and press Shift+J to "Join overlapping Areas"
Note that it takes several seconds to join the areas, on my machine ~12 secs.

One reason for this is that class DeleteCommand calculates a Hashset for thounsands of objects within a loop instead of doing this once outside of the loop. This takes ~ 60% of the complete time.

[GerdP]

In 15874/josm:

see #18728: Join overlapping Areas is slow when combining many complex ways
Improve performance of DeleteCommand.delete() when thousands of ways are removed

Don't calculate set of nodes inside the loop which adds delete commands for the ways, the set doesn't change in this loop.

[GerdP]

In 15875/josm:

see #18728: Join overlapping Areas is slow when combining many complex ways

• use UndoRedoHandler.undo(int num) instead of calling UndoRedoHandler.undo()num times

[GerdP]

The patch 18728.2.patch changes the logic when splitting ways so that only one SequenceCommand is added to undo/redo stack instead of many single SplitWayCommand instances.
This is a bit faster as it avoids to undo/redo the actions to combine them in one command.
More important: If the undo stack contains many (close to undo.max) commands it is less likely that the various temporay added commands remove anything from the stack before they are all undone again.
I think with a small value in undo.max the undo/redo logic is risky, esp. the one which catches the UserCancelException.
JoinAreasAction assumes that all tempoary added actions are on the stack when performing makeCommitsOneAction()

There are more places in the code where this might be done. Working on it...

[GerdP]

18728.3.patch replaces 18728.2.patch and is a much better solution. It builds an internal undo stack and uses the same improvements as the ValidatorDialog when e.g. fixing thousands of duplicated nodes.
Unless all actions are done, nothing is added to the UndoRedoHandler.
This also allows to avoid the dirty trick when a UserCancelException is thrown.

[GerdP]

18728.4.patch also improves handling of "Join areas internal error.". Data changes are reverted before the crash report is produced. I think the old code simply never worked, it left all the commands on the undo stack. I am not sure what to do with the

throw new IllegalArgumentException("Way not circular");

Should I also catch this one or change it to

throw new JosmRuntimeException("Join areas internal error.");

or should I add a new class JoinAreaException and try to write different texts for the different places where it is thrown?

[GerdP]

In 15890/josm:

see #18728: Join overlapping Areas is slow when combining many complex ways

• don't use UndoRedoHandler to store lots of intermediate steps followed by slow undo/redo actions
• catch Exceptions and try to undo actions instead of leaving the undo stack messed up

reduces execution time by ~50% for the complex case

[Don-vip]

Is this ticket fixed?

[GerdP]

Yes, I thought about another change but it didn't improve performance.