#13250 closed enhancement (fixed)
[Patch] JOSM seems to hang after sorting members of a complex relation
Reported by: | GerdP | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 16.07 |
Component: | Core | Version: | |
Keywords: | Performance Relation Editor | Cc: |
Description
Select a multipolygon relation with > 6000 members, e.g. 6040654
Edit the relation
Click on the sort members icon
After a short time (maybe 4 seconds) all members are marked as changed but
JOSM doesn't respond for minutes (no idea how long it will take)
The time is consumed in a loop that invokes
boolean org.openstreetmap.josm.gui.util.HighlightHelper.highlightOnly(Collection<? extends OsmPrimitive> prims)
with an Arraylist, and for this List the contains() method is called.
If I got that right, this is repeated for each member, and the list is growing with each member,
so after some iterations you have a sequential search on thousands of elements, repeated for thousands of times.
Using a Hashset instead of an ArrayList improves performance heavily, but maybe the problem
could be solved better elsewhere. Attached is a patch that shows where to use the HashSet.
Attachments (2)
Change History (8)
by , 9 years ago
Attachment: | member_sort_performance.patch added |
---|
comment:1 by , 9 years ago
Milestone: | → 16.07 |
---|
comment:2 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
by , 9 years ago
Attachment: | memberTable_performance.patch added |
---|
performance patch for relation editor
comment:4 by , 9 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Replying to Don-vip:
thanks for the patch! :)
Thanks for committing :)
I've done a bit more research and - as I thought before - the real problem is that
some routines call the method addSelectionInterval(int index0, int index1)
in a loop which passes the same values for index0 and index1.
This happens for most actions in the relation editor, and thus makes it slow
with relations with many members.
Attached is a 2nd patch memberTable_performance.patch which avoids this problem.
It 1st collects the indices which should be selected in a BitSet and than
calls addSelectionInterval for each group, e.g. if 1,2,3,6,7,8 are selected
it performans two calls (1,3 and 6,8) instead of six. If all +6000 members are selected,
a single call is done within a fraction of a second.
In 10683/josm: