thumbnail-spec: proposing nested thumbnail cache directories

[Alexander Larsson]

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:
> 
>   <cache>/763ab.../dog.jpg
>   <cache>/763ab.../cat.jpg
> 
> 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.