Modify

Opened 20 months ago

Last modified 9 months ago

#6964 new enhancement

Improve Start-up Time

Reported by: simon04 Owned by: team
Priority: normal Component: Core
Version: Keywords:
Cc:

Description

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.

Attachments (5)

6964-from-zip.patch (3.4 KB) - added by simon04 19 months ago.
6964_icon_in_background.patch (2.5 KB) - added by simon04 14 months ago.
6964_validator_init_quickfix.patch (1.5 KB) - added by simon04 14 months ago.
iconInEDT.patch (866 bytes) - added by akks 10 months ago.
2278ms_imagery_preferences.png (37.7 KB) - added by rickmastfan67 9 months ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 20 months ago by 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

Last edited 20 months ago by simon04 (previous) (diff)

comment:2 Changed 20 months ago by 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.

comment:3 follow-up: Changed 20 months ago by 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.

comment:4 in reply to: ↑ 3 ; follow-up: Changed 20 months ago by 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.

comment:5 in reply to: ↑ 4 Changed 19 months ago by simon04

Damn: trac encountered an error and my comment was lost …

Replying to bastiK:

I don't understand (b) and (c). Isn't the jar file a zip file, so you'd have zip inside zip?

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

I'm not sure about this: Could it be that Java gets resources one by one, i.e., reads the jar for every image requested?

I'll attach my changes. The archive images.zip contains images/ and all its content.

Last edited 19 months ago by simon04 (previous) (diff)

Changed 19 months ago by simon04

comment:6 Changed 17 months ago by 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.

comment:7 Changed 17 months ago by simon04

See also #7140.

comment:8 Changed 14 months ago by bastiK

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

comment:9 follow-up: Changed 14 months ago by simon04

In 5134/josm:

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

comment:10 Changed 14 months ago by simon04

In 5135/josm:

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

comment:11 Changed 14 months ago by simon04

In 5136/josm:

see #6964 - speedup presets initialization by some caching

Changed 14 months ago by simon04

comment:12 Changed 14 months ago by simon04

  • Summary changed from Improve Start-up Time to [Patch] Improve Start-up Time

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

comment:13 Changed 14 months ago by akks

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

comment:14 Changed 14 months ago by simon04

In 5138/josm:

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

comment:15 follow-ups: Changed 14 months ago by 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.

Last edited 14 months ago by rickmastfan67 (previous) (diff)

comment:16 in reply to: ↑ 15 Changed 14 months ago by 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.

comment:17 Changed 14 months ago by simon04

In 5139/josm:

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

comment:18 Changed 14 months ago by simon04

  • Summary changed from [Patch] Improve Start-up Time to Improve Start-up Time

comment:19 in reply to: ↑ 15 Changed 14 months ago by 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. :)

comment:20 Changed 14 months ago by 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.

Last edited 14 months ago by akks (previous) (diff)

comment:21 Changed 14 months ago by simon04

In 5151/josm:

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

comment:22 in reply to: ↑ 9 Changed 14 months ago by 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.

Changed 14 months ago by simon04

comment:23 Changed 14 months ago by simon04

In 5177/josm:

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

comment:24 Changed 13 months ago by simon04

In 5195/josm:

see #6964 - display exceptions during parallel startup initialization

comment:25 follow-up: Changed 10 months ago by 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...

Changed 10 months ago by akks

comment:26 in reply to: ↑ 25 Changed 10 months ago by 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.)

comment:27 Changed 10 months ago by bastiK

In 5405/josm:

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

comment:28 Changed 9 months ago by 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)

Changed 9 months ago by rickmastfan67

comment:29 Changed 9 months ago by bastiK

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team. Next status will be 'new'.
Next status will be 'needinfo'.The owner will change to simon04
as duplicate The resolution will be set to duplicate. Next status will be 'closed'.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.