I decided to do some profiling on Thunar startup to find out why it takes 2-3 seconds to popup here using the Gtk+ 2.8 port (while it starts up faster with the full debug build of Gtk+ 2.9). Using Federicos simple access() trick, I found out that the majority of time was spent in
Looking at the relevant parts of the truss output it was very easy to locate the cause of the problem.
gtk_window_realize() loaded the
GtkIconTheme instance for the default screen, which in turn tried to
stat() every icon in Tango and all inherited icon themes. Looking at the Gtk+ source, it shouldn’t
stat() the icon files if an updated
icon-theme.cache file is found. Since I had updated
icon-theme.cache files for all relevant icon theme directories (the truss output also shows that after
stat()ing all icon files, the
icon-theme.cache file is finally used), it should not
stat() the icons, but only the icon directory (according to the Gtk+ source).
So after some further research, I found this patch, which gets applied to the
x11-toolkits/gtk20 FreeBSD port. The patch basicly changes the icon cache loading to first
stat() all icon files in the theme and test if any of them is newer than the cache file. That does of course make the startup slow (the startup of every Gtk+ application on FreeBSD). Whoever came up with that idea was definitely on crack.
Ok, so removed that patch, rebuilt the port, and voila…
1/2 second from startup to
gtk_main(), that’s quite ok. Now whats left over is the question why
gtk_window_size_request() takes that long on first call. Looking at the truss log again, it seems to be the Pango initialization. Have to check this later…
For the sake of completeness, here’s the time it takes to completely open and display (measured as wait for the last expose event) a folder (the thunar source directory, 223 files and folders) in Thunar:
1.3 seconds isn’t that bad for a first unoptimized release. Still room for improvement, tho.