Improve Start-up Time

[simon04]

As further presets, style rules, etc. have been added, the start-up time of JOSM increased.

This ticket should focus some ideas and commits which aim at improving (i.e., reducing) the start-up time.

[simon04]

In [4520/josm]:

see #6964 - Improve Start-up Time by removing blocking queue, concurrency in XmlObjectParser

According to Netbeans' profiling, on my machine, this reduced the time for TaggingPresetPreference.initialize() from ≈3.0s to ≈2.1s and for MapPaintPreference.initialize() from ≈1.2s to ≈0.9s

[stoecker]

One idea would be to do the reloading of mirrored data in background, so maybe data is updated on next start only, but loading is faster.

[simon04]

By (a) resizing the presets icons to 16x16 pixels, (b) putting all images from images/ to a zip archive and (c) putting all images from that archive in a HashMap, I could gain another ≈0.7s for initializing TaggingPresetPreference.

When deploying this, one would need to adapt the build.xml in order to perform the steps (a) and (b) automatically.

[bastiK]

Replying to simon04:

By (a) resizing the presets icons to 16x16 pixels, (b) putting all images from images/ to a zip archive and (c) putting all images from that archive in a HashMap, I could gain another ≈0.7s for initializing TaggingPresetPreference.

When deploying this, one would need to adapt the build.xml in order to perform the steps (a) and (b) automatically.

I don't understand (b) and (c). Isn't the jar file a zip file, so you'd have zip inside zip? There is a trick in web design, where you arrange a large number of icons in a grid on one single image file (in order to save network overhead for many small files). Not sure it is any good for normal desktop applications.

How is (c) different to what ImageProvider does at the moment?

Regarding (a): When the images are never used beyond 16x16, it sounds reasonable to distribute the lower resolution. While you're at it, some icons could be shared between presets and default map style. E.g. there is no reason, to have different bollard symbol for each.

[simon04]

Replying to bastiK:

Replying to simon04:

By (a) resizing the presets icons to 16x16 pixels, (b) putting all images from images/ to a zip archive and (c) putting all images from that archive in a HashMap, I could gain another ≈0.7s for initializing TaggingPresetPreference.

When deploying this, one would need to adapt the build.xml in order to perform the steps (a) and (b) automatically.

I don't understand (b) and (c). Isn't the jar file a zip file, so you'd have zip inside zip? There is a trick in web design, where you arrange a large number of icons in a grid on one single image file (in order to save network overhead for many small files). Not sure it is any good for normal desktop applications.

How is (c) different to what ImageProvider does at the moment?

Regarding (a): When the images are never used beyond 16x16, it sounds reasonable to distribute the lower resolution. While you're at it, some icons could be shared between presets and default map style. E.g. there is no reason, to have different bollard symbol for each.

[simon04]

I tried a different approach: Instead of parsing the tagging presets and constructing the internal data structure on each start, I serialized the object that is returned by TaggingPreset.readAll(source, false) using ByteArrayOutputStream/ByteArrayInputStream.

This has a positive influence for the defaultpresets.xml (new: 565 ms vs. old: 1373 ms), but a negative influence for small presets like Presets/PublicTransportWMasterRoute (new: 122 ms vs. old: 18 ms).

A similar approach should also work for the map paint styles.

[simon04]

See also #7140.

[bastiK]

What about execution stuff parallel in multiple threads. This may help for multi-core machines.

[simon04]

In 5134/josm:

see #6964 - perform several initialization tasks in parallel in order to speedup startup

[simon04]

In 5135/josm:

see #6964 - speedup XmlObjectParser by caching fields/methods used to set values using reflection (speeds up preset parsing among others)

[simon04]

In 5136/josm:

see #6964 - speedup presets initialization by some caching

[simon04]

Another idea to speedup startup: load preset icons in a background thread.

[akks]

This can potentially improve startup greatly - my antivirus is checking presets for 9 sec for example :)

[simon04]

In 5138/josm:

see #6964 - initialize main menu first in order to avoid problems (fix problem introduced in r5134)

[rickmastfan67]

I just wanted to comment that after the tweaks made today, JOSM startup time has become noticeably faster thanks to the tweaks for multi-core CPU's. ;) It now pays off now to have a 6 core CPU in my computer. haha. :)

Now when starting JOSM, it seems to take the longest on the "Initializing validator" line. Everything else is barely seen since they now load 10x faster.

[simon04]

Replying to rickmastfan67:

I just wanted to comment that after the tweaks made today, JOSM startup time has become noticeably faster thanks to the tweaks for multi-core CPU's. ;) It now pays off now to have a 6 core CPU in my computer. haha. :)

:-)

Now when starting JOSM, it seems to take the longest on the "Initializing validator" line. Everything else is barely seen since they now load 10x faster.

That's not really true as several tasks are performed in parallel, but the splash dialog hasn't been adapted yet.

[simon04]

In 5139/josm:

see #6964 - load preset icons in a background thread in order to speedup startup

[bastiK]

Replying to rickmastfan67:

I just wanted to comment that after the tweaks made today, JOSM startup time has become noticeably faster thanks to the tweaks for multi-core CPU's. ;) It now pays off now to have a 6 core CPU in my computer. haha. :)

Yes, it's damn fast. Amazing. :)

[akks]

Sorry if I am writing in wrong ticket, but most likely this is introduced after delayed icon loading:

Main toolbar is showing text together with icons for some of presets buttons. After about a second all pictures are loaded, but text remains and takes a lot of space (almost all 1680 screen width). Also many EDT violations by TaggingPreset.java:1075 are displayed when running from NetBeans.

[simon04]

In 5151/josm:

see #6964 - hide toolbar action text when background image loading finishe

[simon04]

Replying to simon04:

In 5134/josm:

see #6964 - perform several initialization tasks in parallel in order to speedup startup

This broke the validation tests RelationChecker and TagChecker. The reason is that their initialize method requires the tagging presets to be loaded …

The easiest fix would be to perform this initialization upon first run of the validator.

[simon04]

In 5177/josm:

see #6964 - validator initialization requires tagging presets to be initialized

[simon04]

In 5195/josm:

see #6964 - display exceptions during parallel startup initialization

[akks]

I managed to get rid of EDT violations while loading presets icons (that make the log unreadable), but I am not sure the solution is correct. Please, can someone have a look at the patch...

[bastiK]

Replying to akks:

I managed to get rid of EDT violations while loading presets icons (that make the log unreadable), but I am not sure the solution is correct. Please, can someone have a look at the patch...

I'd say it can be done like this and it fixes the EDT violation. You can also consider ImageProvider.getInBackground, because it doesn't block the main worker thread in case of network latency. (Only relevant for presets where icons are specified as "​http://.../someimage.png" in the xml definition.)

[bastiK]

In 5405/josm:

fix EDT violations, don't block main worker thread for preset image loading (see #6964)

[rickmastfan67]

I've just noticed as of late, that when JOSM is starting, it's taking a long time to load the "imagery preferences". On my system, it's taking 2278 ms to load that part. Even on a fresh profile, it's taking ~2231 ms. So, some improvement is needed here as this is a regression because it was a lot faster in the past.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2012-08-12 01:31:10
Last Changed Author: Don-vip
Revision: 5433
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2012-08-12 02:49:21 +0200 (Sun, 12 Aug 2012)
Last Changed Rev: 5433

Identification: JOSM/1.5 (5433 en)
Memory Usage: 154 MB / 2730 MB (96 MB allocated, but free)
Java version: 1.7.0_05, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Operating system: Windows 7

Plugin: OpeningHoursEditor (28477)
Plugin: buildings_tools (28529)
Plugin: mapdust (28412)
Plugin: measurement (28412)
Plugin: mirrored_download (28418)
Plugin: openstreetbugs (28412)
Plugin: reverter (28535)
Plugin: turnrestrictions (28412)
Plugin: undelete (28501)
Plugin: utilsplugin2 (28523)

[bastiK]

I think the splash screen hasn't been adapted to the parallel start, so the times that are displayed don't say much.

[simon04]

The currently non-parallel splash dialog will be addressed in #11355.

[simon04]

Many optimizations have been included, the splash screen now reflects the parallel initialization. Further enhancements can be discussed in a separate ticket (if needed).

[anonymous]

I find this issue in my machine now eventhough I am aware that this bug was filed 7 years ago. What was the fix?

[GerdP]

JOSM was improved. This is an ongoing process as we also add new functionality which adds to the startup time. If you can reproduce poor performance please use Help -> Report Bug to open a new ticket with details about your configuration.

[Hb---]

Users can set --debug to see which part costs the most time. Please see Program arguments.

Simply invoke java -jar josm-tested.jar --debug

Using --trace instead will show every heartbeat.