#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)
Change History (42)
comment:2 by , 13 years ago
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.
follow-up: 4 comment:3 by , 13 years ago
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.
follow-up: 5 comment:4 by , 13 years ago
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 initializingTaggingPresetPreference
.
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 by , 13 years ago
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.
by , 13 years ago
Attachment: | 6964-from-zip.patch added |
---|
comment:6 by , 13 years ago
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:8 by , 13 years ago
What about execution stuff parallel in multiple threads. This may help for multi-core machines.
by , 13 years ago
Attachment: | 6964_icon_in_background.patch added |
---|
comment:12 by , 13 years ago
Summary: | Improve Start-up Time → [Patch] Improve Start-up Time |
---|
Another idea to speedup startup: load preset icons in a background thread.
comment:13 by , 13 years ago
This can potentially improve startup greatly - my antivirus is checking presets for 9 sec for example :)
follow-ups: 16 19 comment:15 by , 13 years ago
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.
comment:16 by , 13 years ago
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:18 by , 13 years ago
Summary: | [Patch] Improve Start-up Time → Improve Start-up Time |
---|
comment:19 by , 13 years ago
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 by , 13 years ago
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.
comment:22 by , 13 years ago
follow-up: 26 comment:25 by , 13 years ago
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...
by , 13 years ago
Attachment: | iconInEDT.patch added |
---|
comment:26 by , 13 years ago
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:28 by , 13 years ago
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)
by , 13 years ago
Attachment: | 2278ms_imagery_preferences.png added |
---|
follow-up: 30 comment:29 by , 13 years ago
I think the splash screen hasn't been adapted to the parallel start, so the times that are displayed don't say much.
comment:31 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 by , 10 years ago
Milestone: | → 15.08 |
---|
comment:33 by , 6 years ago
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 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:35 by , 6 years ago
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 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
comment:37 by , 6 years ago
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 by , 6 years ago
Resolution: | invalid → fixed |
---|
In [4520/josm]:
According to Netbeans' profiling, on my machine, this reduced the time for
TaggingPresetPreference.initialize()
from ≈3.0s to ≈2.1s and forMapPaintPreference.initialize()
from ≈1.2s to ≈0.9s