From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id E15ABBB83 for ; Mon, 14 Aug 2006 16:58:38 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7EEwcxX013546 for ; Mon, 14 Aug 2006 16:58:38 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA15927 for ; Mon, 14 Aug 2006 16:58:36 +0200 (MET DST) Received: from mz2.forethought.net (mzpi4.forethought.net [216.241.36.13]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k7EEwWlj001774 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 14 Aug 2006 16:58:35 +0200 Received: from [216.241.35.41] (helo=[10.0.0.2]) by mz2.forethought.net with esmtp (Exim 4.51) id 1GCdtY-0005QJ-E4 for caml-list@inria.fr; Mon, 14 Aug 2006 08:58:25 -0600 Message-ID: <44E08F95.2070105@gushee.net> Date: Mon, 14 Aug 2006 08:58:29 -0600 From: Matt Gushee User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: caml-list@inria.fr Subject: Weak hashtables & aggressive caching Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44E08F9E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44E08F98.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; hashtables:01 caching:01 hashtable:01 gdkpixbuf:01 caching:01 garbage:01 garbage:01 non-obvious:01 pitfalls:01 wrote:01 ideally:01 functions:01 exists:01 string:02 string:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 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/ :