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 gtk_window_size_request() and gtk_window_realize().

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…

### Update

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.