Opened 15 years ago
Closed 15 years ago
#4725 closed defect (fixed)
Much slower selection list handling since 3102
Reported by: | Ldp | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Core | Version: | |
Keywords: | Cc: |
Description
Since r3102, there's a new and very noticeable lag when selecting many objects.
- Load large dataset (40-50k objects or so)
- Select all/many of them (CTRL-A or selection range)
- The map quickly indicates that they are now selected [1]
- Wait... wait... wait. JOSM is blocking. CPU is 100% on single core. [2]
- The selection list is updated, and you can continue editing.
Steps 4 and 5 are repeated, even if you add/remove a single object from your selection.
Still present in 3122.
[1] Curiously, when having many objects selected, when (de)selecting additional objects the map only updates after the long delay.
[2] On the order of 15+ seconds on my machine, with 40k objects in the selection.
Attachments (0)
Change History (4)
comment:1 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
An unsorted selection list makes finding objects and selecting stuff in the list unusable.
comment:3 by , 15 years ago
Hmm, the sorting available before 3102 didn't really help in finding objects because it wasn't based on the display name in the list. And one could argue that the selection is now (since a couple of months) ordered and that this order is the important order.
Anyway, I'm going to check in an improved sorting shortly. It will be based on the display name. "named objects" (i.e. those not starting with a number) will be displayed before "numbered objects".
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(In [3123]) fixed #4725: Much slower selection list handling since 3102
Removed sorting of the selection list, was too slow.