JOSM is very slow

[simon04]

As reported by HarryKane at ticket:13767#comment:6

I tried again in latest JOSM 11223, but the problem is still there.

Steps to reproduce:

1. Download a layer, have the continuous download plug-in option enabled.
2. Zoom out a bit, so JOSM downloads new surrounding areas.
3. Click the download button again to specify a new area.

You might ask why one does step 3. The reason is that either
a) the download of step 2 takes too long so the user wants to speed up this process by searching the new area (especially when GPS tracks are downloaded) or
b) the user wants to download another area.

In all these cases JOSM is very slow on reacting to the users input and thus hampers the workflow.

[gaben]

Yeah, after clicking on the download button sometimes takes a few seconds for JOSM to respond.

I don't know if it's related to the continuous download plugin, as I'm using it since the beginning.

[taylor.smock]

Have some profiling information:
DownloadDialog.<init> takes 730ms to 1120ms (two profiling runs). I'll use the 730ms run for further numbers. A good chunk was from plugins. I'll see if I can fix those separately. I'll be using that 730ms run as the "base" for now.

BookmarkList.load was the primary problem child (200ms), since it also called ChangesetCacheManager.getInstance. I think we can reduce that significantly with a (relatively) small patch.

src/org/openstreetmap/josm/gui/download/BookmarkList.java

@@ -28 +28 @@
 import org.openstreetmap.josm.data.UserIdentityManager;
 import org.openstreetmap.josm.data.coor.LatLon;
 import org.openstreetmap.josm.data.osm.Changeset;
+import org.openstreetmap.josm.data.osm.ChangesetCache;
 import org.openstreetmap.josm.data.osm.UserInfo;
 import org.openstreetmap.josm.data.preferences.IntegerProperty;
 import org.openstreetmap.josm.data.projection.Projection;
@@ -286 +287 @@
         if (n > 0 && !im.isAnonymous()) {
             final UserInfo userInfo = im.getUserInfo();
             if (userInfo != null) {
-                final ChangesetCacheManager ccm = ChangesetCacheManager.getInstance();
+                final ChangesetCache ccm = ChangesetCache.getInstance();
+                final List<Changeset> changesets = new ArrayList<>(ccm.getChangesets());
                 final int userId = userInfo.getId();
                 int found = 0;
-                for (int i = 0; i < ccm.getModel().getRowCount() && found < n; i++) {
-                    Changeset cs = ccm.getModel().getValueAt(i, 0);
+                for (int i = 0; i < changesets.size() && found < n; i++) {
+                    Changeset cs = changesets.get(i);
                     if (cs.getUser().getId() == userId && cs.getBounds() != null) {
                         model.addElement(new ChangesetBookmark(cs));
                         found++;

[gaben]

I cannot reproduce, happens very rarely.

Usually it takes less than a second, but sometimes even half a minute, so this 730-1120ms is within measure error, I would say.

[gaben]

Wait a second, the wikipedia plugin adds a new tab to the download dialog for Sophox, can it change the situation?

[taylor.smock]

That makes it hard to fix.

If you can attach a profiler next time that happens, that would be helpful.

If you have IntelliJ IDEA Ultimate, you can attach directly to the process. Otherwise, read the docs for ​https://github.com/async-profiler/async-profiler (hopefully you aren't on Windows). Or look into Java Flight Recorder.

---

Yes, the Wikipedia plugin could be changing things. Let me check.

I'm looking at making a PR for svgSalamander that will significantly reduce memory allocations as well.

EDIT: I didn't see anything from wikipedia. I'll have to run a check with all the plugins enabled.