Opened 8 years ago
Closed 8 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 , 8 years ago
Description: | modified (diff) |
---|
comment:2 by , 8 years ago
Cc: | added |
---|
comment:3 by , 8 years ago
comment:4 by , 8 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).