Opened 9 years ago
Closed 9 years ago
#14567 closed defect (fixed)
UI freezes when conflating too many at once
| Reported by: | bagage | Owned by: | team |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Plugin conflation | Version: | latest |
| Keywords: | Cc: | Tyndare |
Description (last modified by )
When conflating 50+ matches at once, JOSM freezes totally and you have no information regarding the progression of the command being executed.
It would be great to have it running in the background while having a progress bar showing how much conflations are left (120 / 140 done), with a cancel button.
Optimizing conflation would be great but is not the core of the issue here I think.
Additional information below.
Build-Date:2017-03-24 10:36:25
Revision:11772
Is-Local-Build:true
Identification: JOSM/1.5 (11772 SVN en) Linux Debian GNU/Linux 9.0 (stretch)
Memory Usage: 829 MB / 1760 MB (611 MB allocated, but free)
Java version: 1.8.0_121-8u121-b13-4-b13, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
Java package: openjdk-8-jre:amd64-8u121-b13-4
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-13
Program arguments: [${HOME}/CL096-CLERIEUX/test-small.osm]
Dataset consistency test: No problems found
Plugins:
+ PicLayer (33148)
+ conflation (0.5.1)
+ jts (32699)
+ rex (26)
+ utilsplugin2 (33182)
Last errors/warnings:
- W: No configuration settings found. Using hardcoded default values for all pools.
Attachments (0)
Change History (4)
comment:1 by , 9 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 9 years ago
| Cc: | added |
|---|
comment:3 by , 9 years ago
comment:4 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Doing conflation in the background seems to be complicated because of all the interactions with the UI. I didn't succeed.
But thanks to your patch conflation time has been dramatically reduced
https://github.com/JOSM/conflation/commit/a3d78a2d8f09a309800625301d119fa9ee67b203
Thanks.



For information, the bottleneck is the RemoveMatchCommand in ConflateMatchCommand::executeCommand. If you comment ConflateMatchCommand.java:83, it behaves much much much better! (25sec for 200 conflations of both geometry and tags against 30 sec for 200 conflations WITHOUT geometry AND tags, eg basically RemoveMatchCommand alone).
I believe operations (appending/removing) on huge lists (800+ items) has poor performance (O(n)?), I will try using LinkedList or another structure to see if it can get better (actually I have no doubt about it).