Weak hashtables & aggressive caching

[Matt Gushee <matt@gushee.net>]

Hello, all--

I wrote a LablGTK-based image viewer this past weekend; one of its 
features is an image cache--specifically, a weak hashtable that contains
values of type string * GdkPixbuf.pixbuf (the string being the file 
name). When a particular image file is requested, it is retrieved from 
the cache if it exists there; otherwise it is loaded from disk (and 
placed in the cache at the same time). This is useful if the user wants 
to quickly look back through a series of images that have already been 
loaded, but it doesn't help with loading images for the first time.

It seems to me it might be useful to implement an aggressive caching 
strategy--i.e., since the files to be loaded are known in advance (from 
the command line), there could be a low-priority thread that would look 
ahead and load images before the user requests them. Of course, if too 
many images are loaded it might trigger the garbage collector, which 
would defeat the whole purpose. Ideally, preloading should stop somewhat 
before garbage collection starts.

 From the documentation, it appears that the GC.stat and GC.control 
functions could be used to regulate the caching behavior, but I have not 
worked with the GC module before. Has anyone done something like this? 
Is it worth the effort? Any non-obvious pitfalls I should be aware of?

-- 
Matt Gushee
: Bantam - lightweight file manager : matt.gushee.net/software/bantam/ :
: RASCL's A Simple Configuration Language :     matt.gushee.net/rascl/ :