Modify

Opened 8 years ago

Closed 8 months ago

Last modified 8 months ago

#6964 closed enhancement (fixed)

Improve Start-up Time

Reported by: simon04 Owned by: team
Priority: normal Milestone: 15.08
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 (4)

6964-from-zip.patch (3.4 KB) - added by simon04 8 years ago.
6964_icon_in_background.patch (2.5 KB) - added by simon04 8 years ago.
iconInEDT.patch (866 bytes) - added by akks 7 years ago.
2278ms_imagery_preferences.png (37.7 KB) - added by rickmastfan67 7 years ago.

Download all attachments as: .zip

Change History (42)

comment:1 Changed 8 years 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 8 years ago by simon04 (previous) (diff)

comment:2 Changed 8 years 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 Changed 8 years 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 ; Changed 8 years 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 8 years 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 8 years ago by simon04 (previous) (diff)

Changed 8 years ago by simon04

Attachment: 6964-from-zip.patch added

comment:6 Changed 8 years 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 8 years ago by simon04

See also #7140.

comment:8 Changed 8 years ago by bastiK

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

comment:9 Changed 8 years ago by simon04

In 5134/josm:

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

comment:10 Changed 8 years 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 8 years ago by simon04

In 5136/josm:

see #6964 - speedup presets initialization by some caching

Changed 8 years ago by simon04

comment:12 Changed 8 years ago by simon04

Summary: Improve Start-up Time[Patch] Improve Start-up Time

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

comment:13 Changed 8 years ago by akks

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

comment:14 Changed 8 years ago by simon04

In 5138/josm:

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

comment:15 Changed 8 years 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 8 years ago by rickmastfan67 (previous) (diff)

comment:16 in reply to:  15 Changed 8 years 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 8 years ago by simon04

In 5139/josm:

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

comment:18 Changed 8 years ago by simon04

Summary: [Patch] Improve Start-up TimeImprove Start-up Time

comment:19 in reply to:  15 Changed 8 years 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 8 years 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 8 years ago by akks (previous) (diff)

comment:21 Changed 8 years ago by simon04

In 5151/josm:

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

comment:22 in reply to:  9 Changed 8 years 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.

comment:23 Changed 8 years ago by simon04

In 5177/josm:

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

comment:24 Changed 8 years ago by simon04

In 5195/josm:

see #6964 - display exceptions during parallel startup initialization

comment:25 Changed 7 years 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 7 years ago by akks

Attachment: iconInEDT.patch added

comment:26 in reply to:  25 Changed 7 years 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 7 years ago by bastiK

In 5405/josm:

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

comment:28 Changed 7 years 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 7 years ago by rickmastfan67

comment:29 Changed 7 years 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.

comment:30 in reply to:  29 Changed 4 years ago by simon04

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

comment:31 Changed 4 years ago by simon04

Resolution: fixed
Status: newclosed

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

comment:32 Changed 4 years ago by Don-vip

Milestone: 15.08

comment:33 Changed 8 months ago by 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?

comment:34 Changed 8 months ago by anonymous

Resolution: fixed
Status: closedreopened

comment:35 Changed 8 months ago by 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.

comment:36 Changed 8 months ago by GerdP

Resolution: invalid
Status: reopenedclosed

comment:37 Changed 8 months ago by 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.

comment:38 Changed 8 months ago by Klumbumbus

Resolution: invalidfixed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


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

 
Note: See TracTickets for help on using tickets.