It seems Federico’s hunch was correct and the majority of time in show_all is spent analysing icon themes and loading the images.
I noticed that /usr/share/icons/gnome/icon-theme.cache was missing, so I ran gtk-update-icon-cache to generate the file and the result was quite significant.
Before:
After:
The total time to execute show_all went from 0.85 to 0.24 seconds, which is a reduction of about 72% and saves over half a second of start up time. I am now left wondering why the icon-theme.cache was not present and whether I have a more responsive desktop as a result of creating the cache. Perhaps we should be running gtk-update-icon-theme-cache as a post-install operation for gnome-icon-theme?
In PLD Linux we do
in all %post and %postun packages that put anything in /usr/share/icons/. In gnome-icon-theme we create the cache in the build root and package it along with the icons.
Hi,
may I ask you an off-topic question? Which program do you use to generate the graph-reports? It seems really cool and can be useful for debugging…
thanks
You absolutely need an up-to-date icon cache for things to be fast. On my box, login with an out-of-date icon cache takes about 35 seconds, and about 12 sec. with an updated cache.
Your distro should already handle the updating of the icon cache when you install a package that installs icons. openSUSE uses a SuSEconfig thing for this; I believe Fedora uses a %postinst or %posttrans. If you installed packages by hand, new-ish Makefiles run gtk-update-icon-cache; yours may not be updated — see sabayon/data/icons/Makefile.am for the incantation that we have all over the place.
Heh, this is most likely a result of building and installing your own versions of gtk+ etc. in /usr and not going through your package manager that would have triggered the gtk-update-icon-theme run. I know that happened to me when I did something similar a year ago http://www.gnome.org/~federico/news-2007-04.html. Fortunately, Gentoo’s ebuilds for packages integrate well with CVS, SVN and git, so now I know always to go through the package manager.
Pescio, please check my blog post yesterday for the link.
Simon, actually I’m using Debian GTK+ packages, but that wouldn’t affect the icon theme cache anyway.
What I mentioned about running gtk-update-icon-cache as a post-install script in gnome-icon-theme applies to all distributions as well as our own tarballs. gnome-icon-theme itself shouldn’t be modified by other packages, so it shouldn’t go out of date. The hicolor icon theme is a different matter of course and any cache for that would frequently go out of date.
I’m now wondering what mileage there is in GTK+ re-building caches itself and storing them in the users home directory somewhere.
I have the debian gtk packages and I was missing the icon theme cache for the gnome theme (that I am using) too! I can’t tell if anything big changed on my system after having fixed the cache.
I think I see a trend of discovering lint and misconfigurations that keep gnome running a bit slow.* Not so long ago I found out about recently used documents[1] that took up 4M by me and caused many applications to launch very, very slowly.
[1]: http://advogato.org/person/gpoo/diary/7.html
*: spoilt as we are, we expect every gnome release to run faster and better, unlike expectations on competing OSes
“I believe Fedora uses a %postinst or %posttrans”
I’m currently submitting a RPM to Fedora. One of the remarks of the reviewer was about icons and the fact that we need to run gtk-update-icon-cache in %post and %postun for *each* package that installs *even only one* icon.
So yes, maybe your distribution should make that mandatory for all packages, this might help speed things up.