GNOME Bugzilla – Bug 430123
[PATCH] Amount of thumbnails slows down GNOME startup linearly
Last modified: 2015-11-14 16:46:22 UTC
Please describe the problem: I have a .thumbnails folder of ca. 430MB at the moment. I started to wonder why I really remember GNOME having started faster, taking into consideration that GNOME 2.14 / 2.16 should have had optimizations, not reduction in speed. I tried to delete .gnome2, .gconf etc. directories, but none helped - until I found out that .thumbnails what was slowing down startup. Now that it wasn't fixed with GNOME 2.18, I decided to file this bug. My GNOME startup (from GDM password prompt to disk activity stopping) is ca. 16 seconds with an empty thumbnails folder, and ca. 23 seconds with the 430MB of stuff. I think the situation is fairly common for any digital camera owner with thousands of photos. Would there be in any possibility not to search the whole .thumbnails directory on startup? I have 6 icons on my desktop, and I also tested that it doesn't help if the desktop would be empty. Why is the nautilus doing what it is doing, then? Steps to reproduce: 1. Time your GNOME startup (after a clean reboot) 2. Fill in the .thumbnails folder with enough data, eg. let Nautilus do thumbnails (maybe of size "large") of several thousands of pictures 3. Time your GNOME startup again (after a clean reboot) Actual results: GNOME startup is _slow_ Expected results: GNOME startup is no slower than with a small .thumbnails folder Does this happen every time? Yes Other information:
http://primates.ximian.com/~federico/news-2007-04.html#20 has a patch for this...
I tried the patch, and it's a step in a good direction (perhaps). It does not however fix the problem. With the patch, background image and other items of the UI are shown earlier in the login process, but the system is unusable until the thumbnails folder browsing has been done. The time it actually takes to login (ie. hard drive stops / you can open Applications menu) seems to stay at the (about) 23 seconds, whether using the patch or not. Of course, this relates to also 1) Nautilus directory browsing being too slow compared to others (bug 362139), 2) it using blocking I/O (bug 104224) and perhaps even that 3) whether thumbnails should be in less than 10000 files if there are 10000 thumbnails.
Good catch. I wrote a small blog entry on this, this is probably libgnomeui trouble: http://blogs.gnome.org/view/cneumair/2007/04/29/0
Created attachment 87248 [details] [review] Proposed libgnomeui patch (RFC) The attached patch gets rid of the entire "~/.thumbnails/fail" cache, and changes the "~/.thumbnails/normal" and "~/.thumbnails/large" cache code to only cache seen image info, and not duplicate the entire file system info. The old code also tended to crash when files inside ~/.thumbnails were removed. This should be fixed as well. Comments, suggestions, benchmarks?
-> libgomeui
chpe, do you think this looks ok?
Have you even measured the performance cost this is gonna give on normal day-to-day work? stats cause disk seeks and disk waits that are enourmously slow compared to any in-memory caches. On the order of hundred of thousands of cycles. Basically, the bet is that one sequential readdir() is much faster than thousands of lookups one-by-one spread out over time. Also, why did you remove the failed cache? That seems to be the most useful one. (i.e. tend to be a small directory that is cheap to read, but its used for every lookup, so we avoid the occasional disk seek when its not in the kernel cache.)
> Have you even measured the performance cost this is gonna give on normal day-to-day work? No, I'm unable to perform a measurement with cold caches since I'm not willing to reboot the machine all the time, and I found no recent lkml info on clearing of kernel disk caches.
(In reply to comment #9) > > Have you even measured the performance cost this is gonna give on normal > day-to-day work? > > No, I'm unable to perform a measurement with cold caches since I'm not willing > to reboot the machine all the time, and I found no recent lkml info on clearing > of kernel disk caches. Hope this helps http://advogato.org/person/leio/diary.html?start=5#drop_caches
(In reply to comment #4) > Created an attachment (id=87248) [edit] > Proposed libgnomeui patch (RFC) I can confirm that this libgnomeui patch reduces my real GNOME startup time by ca. 5 seconds. I haven't noticed any slowdowns because of the patch, and also timed that eg. opening up one photo folder takes the same amount of time (ca. 10 seconds) with or without the patch. Did gnomeui version change, logout/login and drop caches as instructed, a few times. Those actions that have been quick before are still quick, and those that have not been quick (eg. opening photo folder with 1000+ files for the first time) stayed the same. More benchmarks would probably be helpful, if you have any doubts, but from my point of view I'd very much welcome this patch.
Any update on getting the patch in or additional testing? I've been running my desktop computer with the patch without any problems for over a month now.
Anyone got suggestions for how to test this patch?
Basically have Nautilus do thumbnails of thousands of photos, so that your .thumbnails directory has a lot of content (I have ca. 10 000 files taking up over 400MB of space). Then measure the login time of GNOME after reboot (or cache drop) with and without patch. Also try to see if there are any other effects besides the login time speedup, I haven't seen such.
Kjartan: did you test this? Christian: could this go in, or are you waiting for further testing or something else?
> Christian: could this go in, or are you waiting for further testing or something else? Well, Alexander Larsson (comment 8) and possibly some other developers are convinced that we still want a thumbnail cache, so my approach of removing the cache entirely may not be considered the correct solution. The smartest solution may be to create a cache but ignore it until it is filled entirely, which could be done in a separate worker thread. That should lower the pressure we have on the first thumbnail lookups, and still ensure that the cache is present when loading lots of thumbnails at once.
Oh, and I just noted that the - if (priv->reread_scheduled != 0) { - g_source_remove (priv->reread_scheduled); - priv->reread_scheduled = 0; - } - bits are actually wrong. This is the timeout for rereading the GConf thumbnailers, not the MD5 directory.
Ie. you removed the in-memory cache, not the thumbnail cache (.thumbnails) which I think of as the feature itself :) In my benchmarking I didn't notice already-thumbnailed folders opening any more slowly than without the patch, though I agree that this should probably be probably profiled with proper tools, I just haven't done such myself. Should the bug status be changed to non-assigned so that other people see that they could jump in to help? Anyway, this problem prevents a GNOME system from starting up fast on any computer that is used to display photos or other image files, it just takes so long time for any 7200rpm (or 10k for that matter) hard drive to seek through 10k files.
I've had really slow startup times recently, then saw this bug mentioned on #g-h. With about 600MB of 'large' thumbnails, there's a delay of about 5-15 seconds when logging in -- all I see is a mouse cursor and a lot of disk activity. Without that cache, the desktop starts within a few seconds, and I get the background very quickly. I have a lot of 'large' thumbnails because I have thousands of images in f-spot. So this bug is likely to hit quite a few users in a thoroughly evil way. Got a photo album? Got pain! ;-)
After some consideration I've come to the conclusion that we should remove the cache and instead rely on special (possibly not yet existant) in-memory file systems: http://blogs.gnome.org/cneumair/2007/08/29/thumbnail-followup-2/
Adding perf keyword for easier tracking. One part of the problem could also be that stale thumbnail files are never removed, making the .thumbnails directories larger than they could be. Also good to see one of my old blog post was actually useful to someone ;)
Maybe you should have a look at this discussion: http://www.mail-archive.com/xdg@lists.freedesktop.org/msg03369.html which refers to this standard: http://jens.triq.net/thumbnail-spec/index.html (obviously used by Gnome)
Patch doesn't apply cleanly to svn trunk anymore.
Yep, hunks 9 - 14 do not apply on SVN trunk any more. Christian N., could you do a new patch based on your patch from 2007-04-29? Or are you only considering the in-memory filesystems options now? I'd like to have acceptable GNOME startup for myself at least, though. I'll probably attempt to apply the patch when I move to 2.22. It looks like it'd still apply with some manual editing.
To deal with this issue from another angle, I've submitted a patch (bug 523159) to add a gnome_thumbnail_purge_cache function to libgnomeui. Would someone take a look at that? - Mike
Starting with gnome 2.23.x, the oldest thumbnails are deleted if the cache exceeds 64 MB, or if they are older than 60 days. See bug 523159. Closing as fixed. - Mike
Reopening as there is no reason whatsoever for startup to be slow with many thumbnails, regardless of those being nuked periodically or not by g-s-d. This bug indicates that there would still be a difference in if there is 1MB or thumbnails or 64MB of thumbnails, and it shouldn't be. g-s-d is just making the issue make less of an impact.
Retitling as the g-s-d pruning should make it not be 5+ seconds on thumbnails munching :)
I agree on reopening, I'd rather like not to be forced to rethumbnail photo images each time when viewing them in eg. gThumb, or as an other option take the login performance hit if I disable the pruning. I've currently 900MB in .thumbnails, so I guess only tiny portion of my photos' thumbnails would fit in the new limit.
Timo, The g-s-d limit is adjustable, of course, in gconf-editor. There's no UI for it, though. 64 MB should hold ~3200 normal thumbnails. 900 MB should hold 45000. Seems like a lot! Anyway, by all means, please fix the underlying issues :-) - Mike
Let's get rid of the cache. GVFS doesn't use it either: http://svn.gnome.org/viewvc/gvfs/trunk/daemon/gvfsbackend.c?view=annotate#l365 The next step would be to re-write the thumbnail spec to put all thumbnails from the same source directory into a distinct thumbnailing destination directory, instead of putting everything into one single directory - but this is orthogonal.
Created attachment 111186 [details] [review] Proposed patch I've rewritten the patch against trunk.
Ping.
Patch looks ok to me. Kjartan?
Maybe we should take this for a spin in 2.23.x at least?
Agreed. I created a gnome-2-22 branch for libgnomeui; let's take this on trunk.
Thanks, committed: http://svn.gnome.org/viewvc/libgnomeui?view=revision&revision=5614 Closing as fixed.
I'd like to know a few things, to check if I understand correctly - g-s-d clears the cache when it gets big? (is this still the case?) - the thumbnail cache is gone entirely? - ??? I'm confused. And this patch is against 2.22? Basically, please tell an end-user like me what to understand from this (what would be the consequences of... uh, cherry-picking svn 5614?). This is so I can figure out if it would be worthwhile to file a bug against my distro.
Jean-François, 1) g-s-d clears the filesystem thumbnail cache when it gets big. 2) The above patch removed an in-memory thumbnail cache, which is different than the filesystem cache. I doubt any distro would find it worth back-porting the patch. - Mike
> I doubt any distro would find it worth back-porting the patch. Just in case any distributor considers this: You will need http://svn.gnome.org/viewvc/libgnomeui/trunk/ChangeLog?revision=5614&view=markup http://svn.gnome.org/viewvc/libgnomeui/trunk/ChangeLog?revision=5615&view=markup i.e. the changes between revision 5613 and 5615.
(In reply to comment #39) > 2) The above patch removed an in-memory thumbnail cache, which is different > than the filesystem cache. Does that mean that the startup time with lots of thumbnails doesn't increase linearly anymore with this change? It sounds like the state in this is the same, so is this bug (the original thing) really fixed?