Performance issues after updating

[ukash63@…]

Description

After upgrading JOSM from version 15806 to 15937 there is noticeable performance loss when moving nodes, ways or sometimes when adding tags. I noticed higher cpu usage. Downgrading to previous version (15806) fixes problem.
I have tested it on two different computers (with the same operating system).

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

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-02-26 10:50:27 +0100 (Wed, 26 Feb 2020)
Revision:15937
Build-Date:2020-02-26 09:52:41
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15937 pl) Linux Arch Linux
Memory Usage: 207 MB / 4008 MB (92 MB allocated, but free)
Java version: 13.0.2+8, N/A, OpenJDK 64-Bit Server VM
Screen: :0.0 2560x1440
Maximum Screen Size: 2560x1440

[Don-vip]

Can you please test various snapshots between r15806 and r15937 to help us to narrow the range of revisions where the problem was introduced? You can download them here: https://josm.openstreetmap.de/download/

[ukash63@…]

I have tested and problem was introduced in snapshot 15889.

Snapshop 15887 does not have this issue.

[GerdP]

Changes in r15889 were done for #14088

[simon04]

I've performed a performance test: for every primitive in source:trunk/nodist/data/neubrandenburg.osm.bz2​, an image is obtained. Here are the results for r15806, r15888, r16053:

test/performance/org/openstreetmap/josm/gui/mappaint/MapRendererPerformanceTest.java

@@ -170 +174 @@
         MapPaintStyleLoader.reloadStyles(defaultStyleIdx);
     }
 
+    @Test
+    public void testImageProviderGetPadded() {
+        final LongSummaryStatistics statistics = new LongSummaryStatistics();
+        for (int i = 0; i < 3; i++) {
+            final Stopwatch stopwatch = Stopwatch.createStarted();
+            for (OsmPrimitive primitive : dsCity.allPrimitives()) {
+                ImageProvider.getPadded(primitive, ImageProvider.ImageSizes.SMALLICON.getImageDimension());
+                // if (primitive.isTagged()) MapPaintStyles.getNodeIcon(primitive.getKeys().getTags().iterator().next());
+            }
+            statistics.accept(stopwatch.elapsed());
+        }
+        System.out.println(statistics);
+        // r15806 MapPaintStyles.getNodeIcon LongSummaryStatistics{count=3, sum=23827, min=4564, average=7942.333333, max=11388}
+        // r15806 ImageProvider.getPadded    LongSummaryStatistics{count=3, sum=55536, min=18056, average=18512.000000, max=19324}
+        // r15888 MapPaintStyles.getNodeIcon LongSummaryStatistics{count=3, sum=24332, min=5063, average=8110.666667, max=11515}
+        // r15888 ImageProvider.getPadded    LongSummaryStatistics{count=3, sum=57233, min=18730, average=19077.666667, max=19731}
+        // r16053 MapPaintStyles.getNodeIcon LongSummaryStatistics{count=3, sum=29961, min=6784, average=9987.000000, max=13779}
+        // r16053 ImageProvider.getPadded    LongSummaryStatistics{count=3, sum=5354, min=1541, average=1784.666667, max=2245}
+        // r16053 ImageProvider.getPadded    LongSummaryStatistics{count=20, sum=31170, min=1494, average=1558.500000, max=2200}
+    }
+
     private static class PerformanceTester {
         public double scale = 0;
         public LatLon center = LL_CITY;

@team, any ideas/hints what might have caused this performance regression?

[stoecker]

I'd say the only image related changes where your changes to SVG.

[GerdP]

Sorry, can't help here. For me, both r15887 and r15889 are equally slow. No idea if this is relevant here: The objects which are moved are not the same. Different oneway roads are effected and maybe the arrows for them are important?

[ukash63@…]

I've checked it on another computer (MacOS) and there's also this slowdown noticable. It happens even when I grab point that is not connected to anything.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-02-21 21:19:34 +0100 (Fri, 21 Feb 2020)
Revision:15889
Build-Date:2020-02-22 02:30:59
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (15889 pl) Mac OS X 10.15.2
OS Build number: Mac OS X 10.15.2 (19C57)
Memory Usage: 385 MB / 2048 MB (109 MB allocated, but free)
Java version: 13.0.2+8, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 69732928 1680x1050, Display 1127222057 1920x1080, Display 1127222050 1920x1080
Maximum Screen Size: 1920x1080
Dataset consistency test: No problems found

[simon04]

Err, since r15889, org.openstreetmap.josm.tools.ImageProvider#paddedImageCache uses Image as key, likely causing expensive hashCode computations. I'm trying to move this cache into the individual ImageResource instances.

[simon04]

In 16060/josm:

see #18871 - ImageProvider.getPadded: fix/improve performance

[simon04]

In 16062/josm:

see #18871 - fix MapCSSRendererTest.testRender[way-repeat-image]

[simon04]

In 16074/josm:

fix #18884, see #18871 - ImageResource.imgCache: use ConcurrentHashMap

[Don-vip]

@simon: Is the performance regression fixed?

[simon04]

Most likely since the issue described in comment:10 has been addressed.

[Don-vip]

I just tried to move a single node, with a small data set, and it is extremely slow.

[Don-vip]

r15887 is fine. r15889 is slow. r16173 is as slow as r15889, so the original issue is not fixed.

[Don-vip]

When I move a tagged node, this is where most of the CPU is spent:

It likely comes from the update of selection list:

[GerdP]

Would match my results. I have preference properties.presets.visible=false

[GerdP]

No, sorry, forget that. The setting is not about the icon for the selected element.

[Don-vip]

In 16186/josm:

fix #18871 - fix performance regression - padded icons requests made unnecessary costly rescale operations

[simon04]

Vincent, big thanks for looking into and fixing this issue!

[Don-vip]

You're welcome :) One further improvement would be to not refresh the padded icon in selection list for movement events. I'm not sure if it's doable easily.

[Don-vip]

Ticket #19031 has been marked as a duplicate of this ticket.