[Patch] Ctrl + A (Select all) is slow

[GerdP]

What steps will reproduce the problem?

1. Download some data e.g. a small city with ~100.000 objects
2. Zoom to a small area
3. Use Ctrl+A to select all data or maybe a Search that returns all objects in the layer

What is the expected result?

Fast reaction

What happens instead?

Slow reaction, esp. when the "Selection List Window" is open

Please provide any additional information below. Attach a screenshot if possible.

I think one reason for the poor performace is that various instances of JosmAction use OsmUtils.isOsmCollectionEditable(selection) which is rather slow.
If the current data layer is not locked, this method iterates over all elements.
I wonder if that makes sense. Is it possible that the collection passed to OsmUtils.isOsmCollectionEditable() contains data from different layers?
If not, it would be enough to check a single element. If yes, do we have to use this method in all cases?
For example, updateEnabledState() in ModeNodeAction could easily be changed to check selection.size() == 1 first.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-07-09 01:47:59 +0200 (Mon, 09 Jul 2018)
Revision:14026
Build-Date:2018-07-08 23:50:14
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (14026 en) Windows 10 64-Bit
OS Build number: Windows 10 Home 1803 (17134)
Memory Usage: 256 MB / 6144 MB (76 MB allocated, but free)
Java version: 10.0.1+10, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1920x1080
Maximum Screen Size: 1920x1080

Plugins:
+ OpeningHoursEditor (34389)
+ apache-commons (34389)
+ buildings_tools (34212)
+ download_along (34389)
+ ejml (34389)
+ geotools (34125)
+ jts (34206)
+ measurement (34206)
+ o5m (34389)
+ opendata (34389)
+ pbf (34389)
+ poly (34389)
+ reverter (34271)
+ utilsplugin2 (34389)

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[GerdP]

Reg. the Selection List Window:
The main problem here is that method org.openstreetmap.josm.tools.ImageProvider.get(OsmPrimitiveType type) is called very often (twice for each element in the list). Each call uses getIfAvailableImpl() which does quite a lot of computations before it finally finds the result in the cache. All this happens in a synchronized block.
The attached quick+dirty patch improves performance of the Selection List Window a lot but maybe has unwanted side effects.

I think the synchronized routine which checks + updates the cache should be as simple as possible, all other calculations should be done before calling it.
Comments?

[Don-vip]

I don't understand the patch:

• why "data" subdir in particular?
• what exact expensive operation it avoids?

[GerdP]

Replying to Don-vip:

I don't understand the patch:

• why "data" subdir in particular?

Because the standard icons for nodes, ways and rels are searched in this directory. When the selection contains e.g. 100000 nodes the search is performed 100000 times. Maybe it would be better to store the result somewhere else instead of changing getIfAvailableImpl(), e.g.
in org.openstreetmap.josm.gui.PrimitiveRenderer.renderer(Component def, IPrimitive value, boolean fast).
If parameter fast is true this routine could maintain its own cache. Another more general approach is implemented in patch cache_v2.patch.

• what exact expensive operation it avoids?

Quite a lot of string operations like concatenation and indexOf() and the two small nested loops which are fully executed for each search.

[Don-vip]

In 14238/josm:

fix #16510 - improve performance of Ctrl-A by caching icons used to display OSM primitive types

[GerdP]

Sorry for the late response, I was cycling for a while. Just compared #14268 with #14178. Works much faster now :)