Re: [Caml-list] Weak hashtables & aggressive caching

[skaller <skaller@users.sourceforge.net>]

On Tue, 2006-08-15 at 06:23 +0900, Jacques Garrigue wrote:
> From: Matt Gushee <matt@gushee.net>
> 
> > 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.
> 
> I wonder how you trigger the GC, to both keep the cache long enough,
> and to avoid filling the memory too much, and resulting in lots of
> swapping.

I'm confused. First, a pixmap doesn't have any pointers in it,
so it doesn't need to be scanned by the GC.

Second, you'd need a LOT of images to come even close
to running out of address space (on a 64 bit machine anyhow :)

And third, there would be no swapping, unless you were 
flicking between the images .. in which case there'd
be swapping no matter what.

> Considering the difficulties avoid memory overflow,

I have thousands of images and I can scan them at full size
very fast with GQView .. I can only barely see the drawing
happen .. it almost keeps up with the keyboard repeat rate
at full screen size .. and that includes *scaling* the images.
Mind you .. GQView is extremely quick and it knows when to move on
(interrupts rendering when you tell it to view a new image).
(this is with a low end nVidia card on an amd64 3200 single core/1GRam)

Lets get real here: the difficulties arise editing video,
not still pictures.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net