Created attachment 3087 performance trace with 4.7.1 We noticed that xfce4-keyboard-settings takes about two seconds to start on a slow embedded system. Using the approach from [1] I added some profiling points to main() and the dialog setup in xfce_keyboard_settings_constructed(), which showed that the construction of the keyboard model combo box took one second, half of the startup time. Since the keyboard layout tab is not the tab shown by default, and is usually even grayed out, I think it is acceptable to take out this part and move it into a g_idle_add(). [1] http://people.gnome.org/~federico/news-2006-03.html#login-time-2
Created attachment 3088 performance trace with the patch applied With the patch, the trace now looks like this, and xfce4-keyboard-settings now starts up in just under a second. I tested that the layout combo box still works fine.
Created attachment 3089 patch against git head Finally, the patch. Thanks for considering!
What happens if you move gtk_combo_box_set_model() after the foreach call?
Nick, if you do that, you'll get tons of (xfce4-keyboard-settings:8956): Gtk-CRITICAL **: gtk_list_store_set_valist: assertion `GTK_IS_LIST_STORE (list_store)' failed (xfce4-keyboard-settings:8956): Gtk-CRITICAL **: gtk_list_store_append: assertion `GTK_IS_LIST_STORE (list_store)' failed and an empty combobox. That's because xfce_keyboard_settings_add_model_to_combo() calls gtk_combo_box_get_model(), which isn't set yet at that time. So we'd need to add the local list_store variable to the settings struct, to pass it around. Why do you ask, do you think it'd make any performance difference if you initialize the list store before assigning it to the combo box? (that'd weird; unless you mean that this would save us a hundred gtk_combo_box_get_model() calls, but I suppose they are cheap (and presumably compiler optimized) compared to the gtk_builder_get_object() call which we do in each iteration.
Created attachment 3091 Connect to widget after model is filled I mean like this. GtkComboBox responds to each insert (shouldn't be a lot tho) and the object lookups are also unneeded. If this is hardly an improvement we can go with the idle, but I'm not a huge fan of idle stuff in startup interfaces (idle still runs in the same thread, so if shows faster, but the interface is still blocked a little while after it is shown) and I'd say loading the xkl config would take some time, so if we go idle; do all the xkl tasks in the idle.
Created attachment 3102 trace before "anothertry.patch" Indeed this reduces the time to initialize the models combo box from 1 s to ~ 0.3 seconds, nice job! So it seems the combo box does some nontrivial things each time you change its model, even if it's not displayed. I used a very reduced tracing instrumentation this time, so for reference I attach the before/after your patch graphs again. Thanks!
Created attachment 3103 trace after "anothertry.patch"
Ok will commit my patch then (rev f254a7a), since it solves the problem instead of 'hiding' it in an idle. Thanks a lot for testing this, I really appreciate it people look at the code this way.