thumbnail-spec: proposing nested thumbnail cache directories
alexl at redhat.com
Mon Sep 10 04:11:52 PDT 2007
On Fri, 2007-09-07 at 18:02 +0000, Thomas Leonard wrote:
> On Thu, 30 Aug 2007 12:06:10 +0200, Christian Neumair wrote:
> > Dear xdg list,
> > Over at GNOME land we have the problem that due to the huge size of the
> > thumbnail directories, refreshing in-memory thumbnail readdir() caches
> > takes very long.
> > The caches are required as thumbnails are looked up for *every* file one
> > opens with the file manager, so the cumulative performance impact is
> > significant.
> > http://blogs.gnome.org/cneumair/2007/04/29/thumbnail-followup/
> > http://blogs.gnome.org/cneumair/2007/08/29/thumbnail-followup-2/
> > Alexander Larsson proposed to reduce this delay massively by using
> > nested directories - git does that as well:
> > The first two digits of the MD5 hash "4f831f...89" would be split apart,
> > and used to create a subdirectory "4f". The thumbnail file corresponding
> > to the specified example in this directory would then be named
> > "831f...89.png". So the entire hash maps to the file "4f/831f...98.png"
> > rather than "4f831f...98.png"
> The problem with this is that to render one directory of images you need
> to open a lot of thumbnails directories, evenly distributed. Also, it's a
> hack to work-around a filesystem problem. A better scheme would be to
> md5sum the name of the directory containing the image, e.g. thumbnailing
> a directory containing 'dog.jpg' and 'cat.jpg' would create/access:
> Thus you get all the images you need together in the cache. Also helps
> with deleting/renaming directories.
> This was suggested by Rasterman a while ago, IIRC. If we're going to
> change the spec, I'd prefer to change to that.
This sounds good to me too.
More information about the xdg