Federico wrote:
Simon Holm Thøgersen looked a bit more into yesterday’s timeline, and he found that Nautilus causes all of ~/.thumbnails to be scanned when creating the desktop window. The thumbnails will need to be read eventually when displaying the files in ~/Desktop, but definitely not when the desktop is being initialized.
This is a very good catch.
I investigated the libgnomeui thumbnailing code. When the first thumbnail is looked up, it seems to read the entire thumbnail directory, and add all existing thumbnail files to the global thumbnail cache, which will cause readdir(), and malloc() calls. It will then save the thumbnail directory’s mtime and a thumbnail is requested, it will stat the entire directory again if a thumbnail is changed (and thus changed the directory’s mtime).
Denoting whether a thumbnail file is present or not is the file system’s job, there is no point in duplicating the FS info in a hash table.
It would IMO be way better to just purge the cache containing all thumbnails, and instead only cache the previously requested ones. We’d directly stat() each thumbnail file, and store and cache the mtime per thumbnail file in a hash table containing only the previouly-seen thumbs, and check whether the requested one matches the cached one.
I’ll do some more investigations and report about my findings, but this looks like it may well be the reason that users report desktop startup speed differences of orders of magnitude, depending on the number of stored thumbnails.
Update
I submitted a libgnomeui patch against the related bug report (#430123). Even with a warm filesystem cache, the subjective Nautilus startup could be significantly reduced with a ~160 MB thumbnail cache.