thumbnail-spec: proposing nested thumbnail cache directories

[Thomas Leonard]

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.


-- 
Dr Thomas Leonard		http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1