Improve preferences dialog startup time

[Don-vip]

As JOSM grows, I noticed the preferences dialog takes more and more time to load.
Indeed, the build() method takes, without any plugin, more than 500ms, I think we can do better.

I've measured the time spent in the dialog construction to find the slowest preferences tabs (this is the time spent in addGui()):

org.openstreetmap.josm.gui.preferences.ShortcutPreference -> 115 ms
org.openstreetmap.josm.gui.preferences.ServerAccessPreference -> 56 ms
org.openstreetmap.josm.gui.preferences.ImageryPreference -> 51 ms
org.openstreetmap.josm.gui.preferences.LanguagePreference -> 45 ms
org.openstreetmap.josm.gui.preferences.MapPaintPreference -> 41 ms
org.openstreetmap.josm.gui.preferences.DrawingPreference -> 24 ms
org.openstreetmap.josm.gui.preferences.ColorPreference -> 22 ms
org.openstreetmap.josm.gui.preferences.advanced.AdvancedPreference -> 18 ms
org.openstreetmap.josm.gui.preferences.ValidatorPreference -> 14 ms
org.openstreetmap.josm.gui.preferences.PluginPreference -> 14 ms
org.openstreetmap.josm.gui.preferences.TaggingPresetPreference -> 11 ms
org.openstreetmap.josm.gui.preferences.ToolbarPreferences$Settings -> 10 ms
org.openstreetmap.josm.gui.preferences.BackupPreference -> 9 ms
org.openstreetmap.josm.gui.preferences.RemoteControlPreference -> 7 ms
org.openstreetmap.josm.gui.preferences.LafPreference -> 6 ms
org.openstreetmap.josm.gui.preferences.ProjectionPreference -> 3 ms
org.openstreetmap.josm.gui.preferences.AudioPreference -> 1 ms

[bastiK]

Maybe we can delay the building of the tabs till they are selected.

[akks]

And reorder them too http://josm.openstreetmap.de/ticket/7299#comment:3 :)

[Don-vip]

Replying to bastiK:

Maybe we can delay the building of the tabs till they are selected.

I tried, but this requires to change PreferenceSetting interface, as we need to know the tab icon and tooltip before building the GUI. This would require a change in all the plugins that use preferences, is it acceptable ?

In the meantime we can improve our own tabs. For example I found why ShortutPreference is so slow on the first time, it is due to this piece of code in PrefJPanel:

    // A list of keys to present the user. Sadly this really is a list of keys Java knows about,
    // not a list of real physical keys. If someone knows how to get that list?
    private static Map<Integer, String> keyList = setKeyList();
    
    private static Map<Integer, String> setKeyList() {
        Map<Integer, String> list = new LinkedHashMap<Integer, String>();
        // I hate this, but I found no alternative...
        for (int i = 0; i < 65534; i++) {
            String s = KeyEvent.getKeyText(i);
            if (s != null && s.length() > 0 && !s.contains("Unknown")) {
                list.put(Integer.valueOf(i), s);
                //System.out.println(i+": "+s);
            }
        }
        list.put(Integer.valueOf(-1), "");
        return list;
    }

[Don-vip]

By the way this doesn't work with a non English locale:

            if (s != null && s.length() > 0 && !s.contains("Unknown")) {

"Unknown" is translated by Java.

[Don-vip]

In 4929/josm:

see #7386 - Do not list unknown keyCodes when using a non-English locale

[stoecker]

Searching from 0 to 1000, 61000 to 61999 and 65000 to 65534 (65534 should be included) should reduce sorting space a lot.

[stoecker]

See ​http://docs.oracle.com/javase/6/docs/api/constant-values.html#java.awt.event.KeyEvent.KEY_LOCATION_LEFT.

[Don-vip]

In 4930/josm:

see #7386 - Speed up keyCodes retrieving (from ~50ms to 1ms only)

[stoecker]

Nice.

[bastiK]

Replying to Don-vip:

Replying to bastiK:

Maybe we can delay the building of the tabs till they are selected.

I tried, but this requires to change PreferenceSetting interface, as we need to know the tab icon and tooltip before building the GUI. This would require a change in all the plugins that use preferences, is it acceptable ?

I'd say it's worth the trouble, preference start is definitely too slow at the moment.

[Don-vip]

In 4931/josm:

see #7386 - Speed up languages JComboBox initialization (from ~40ms to 5ms only)

[stoecker]

The next tested is a cleanup release anyway (dropped all deprecation and reworking shortcuts and a lot of other old stuff). So go on and design a better interface which can speedup the preference loading before we do the release.

When doing so: It should be possible to call preferences dialog with a preferences section and also a sub-tab preselected. I think first was implemented by Frederik, don't know about second.

[Don-vip]

Replying to stoecker:

The next tested is a cleanup release anyway (dropped all deprecation and reworking shortcuts and a lot of other old stuff). So go on and design a better interface which can speedup the preference loading before we do the release.

This was more complex than I thought, but it's done :) It's such a pleasure to view preferences dialog as soon as you press F12 :)

When doing so: It should be possible to call preferences dialog with a preferences section and also a sub-tab preselected. I think first was implemented by Frederik, don't know about second.

Yes, I've seen that, it's used in color dialog to launch preferences dialog with "Display" tab and its second sub-tab preselected. It works :)

[Don-vip]

In 4968/josm:

fix #7386 - Major rework of preferences GUI settings in order to speed up preferences dialog startup time. The building of each preferences tab is delayed until this tab is selected. Plugins that use preferences will need to make some (minor) changes.

[Don-vip]

In 4969/josm:

fix #7386 for good - Don't know why these files have been skipped from previous commit.

[stoecker]

Some work to be done. JOSM produces a lot of NullPointer exceptions when clicking ok without viewing tabs (plugins, serverprefs, validator, ...).

[stoecker]

Sadly this killed my toolbar prefs.

[Don-vip]

In 4970/josm:

see #7386 - call ok() only on initialized settings + fix NPE in plugins management

[Don-vip]

Replying to stoecker:

Sadly this killed my toolbar prefs.

Sorry for that :( Does r4970 fix it ?

[stoecker]

Replying to Don-vip:

Sorry for that :( Does r4970 fix it ?

I think so.

[Don-vip]

Ticket #6392 has been marked as a duplicate of this ticket.

[simon04]

What about using a singleton instance of PreferenceDialog as further enhancement?

[akks]

I am not sure it is worth it. PreferenceDialog itself is not heavy. Currently almost all preferences and cache reading, layout, and more other work is done when opening tab.

If it is done only once, there can be problems with reflecting preferences changes.

Listeners and major rework of tabs will be needed, and in the end almost the same amount of work will be done when preference tab open.