I’m sure I’m not the only person to have noticed that gnome-appearance-properties takes quite a while to start up. On my system (a 2GHz Athlon XP), it takes an incredible three seconds to start this little preferences application.
So, I decided to do something about it. I used the Federico Technique to insert some debug messages to create a graph of the start up process.
My first attempt produced this graph:
From this, it is clear there are a few bottle necks during start up, with desktop_init being the biggest. desktop_init is the function that initialises the desktop backgrounds tab of the capplet. So, to investigate quite why this was taking such a long time to complete, I added some more log points.
From this, it was quite clear that the time was being consumed entirely by creating the file chooser widget, used when users want to add new backgrounds to their list. So I added yet more log messages to determine if there was one or more function calls responsible:
It turns out that the gtk_file_chooser_dialog_new_with_backend() function is taking just over 1.5 seconds to complete, or approximately half the start up time for the entire application. Thankfully, the widget is not required until the user actually clicks the “Add Wallpaper” button, so by delaying the creation of the widget, we can reduce start up time by half.
There are clearly some more places to investigate and I’ve started looking into the app data init and themes_init sections.
The next biggest places to investigate appear to be the gnome_theme_init, thumbnail generation and the style_init. However, the biggest block by far appears to be show_all, which is now taking up almost half the startup time.
Does anyone know have any ideas about why gtk_file_chooser_dialog_new_with_backend() took so long to finish, and indeed why the show_all function take so long to complete? Would it be practical to only call gtk_widget_show when the tab becomes active? I suppose there is only one way to find out…
Nicely done.
W00t. Glad that you found the plotting script useful 🙂
The file chooser is slow to instantiate the first time because it has to dlopen() or mmap() a ton of shit:
– libbeagle (ooh, we may be able to delay this!)
– libgvfsdbus
– libhal
– libgiohal-volume-monitor
– libgio file system module
– libuuid
– mime.cache
– more icons from your icon cache
Not everything is a direct dependency, of course.
So, even with a warm cache, you’ll spend some time in the linker 🙁
show_all() is slow because:
1. Code for the widgets has to be paged in.
2. size_request() is expensive because you must load icons in order to figure out the size they need. You must measure fonts for text strings (load the fonts, process them, etc.). You must load the translations to know the strings you are going to show!
3. size_allocate() tends to be cheap, since you already have all the info you need.
4. realize() can get expensive if you need to pixmapify things.
5. map() tends to be cheap.
6. The initial expose() tends to be pretty expensive. You must actually page in icon data, theme engine code, etc.
In general, the biggest hit during the initial show_all() is loading graphics (icons, etc.) and creating widgets that will not be visible when the UI appears. You may be able to delay some of that until it’s actually needed.
Tip: since you already have an strace with the “MARK” thingies, grep between the marks that wrap the show_all for the open() syscall. That may give you an idea of what files are being loaded (icons? backgrounds?).
(I vaguely recall that the background capplet would load all the backgrounds before showing itself, and libjpeg *is* pretty slow… is this still the case? If so, you could load the images *only* if they’ll actually be shown on the screen; load new ones as the user scrolls them in.)
Thanks for all your “investigatory” work!
When I was debugging why the *first* dialog’s “show all” was slow on one of our applications at work, I found that if you show all on a dialog with nothing but a button with a label, it was fast. As soon as anything involved stock icons from the theme, the show all became *much* slower.
Just a guess based on my experience, it certainly could be plenty of other things though.