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 3EAABBB83 for ; Mon, 14 Aug 2006 23:48:33 +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 k7ELmW3e017450 for ; Mon, 14 Aug 2006 23:48:32 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id XAA20380 for ; Mon, 14 Aug 2006 23:48:31 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7ELmTIj017439 for ; Mon, 14 Aug 2006 23:48:30 +0200 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id k7ELNdEv029728; Tue, 15 Aug 2006 06:23:40 +0900 (JST) Date: Tue, 15 Aug 2006 06:23:35 +0900 (JST) Message-Id: <20060815.062335.55488138.garrigue@math.nagoya-u.ac.jp> To: matt@gushee.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] Weak hashtables & aggressive caching From: Jacques Garrigue In-Reply-To: <44E08F95.2070105@gushee.net> References: <44E08F95.2070105@gushee.net> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44E0EFB0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44E0EFAD.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; hashtables:01 caching:01 hashtable:01 gdkpixbuf:01 ocaml:01 allocations:01 caching:01 lablgtk:01 wrote:01 caml-list:01 exists:01 data:02 data:02 structures:02 structures: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 From: Matt Gushee > 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. With ocaml data structures, the GC does a good job, as it is triggered everytime already allocated memory is filled. Hopefully this means that the memory set should not increase. But with external data structures like pixbufs, the GC is called in a pre-programmed way, currently at least after every 10 pixbuf allocations. This is probably too much for your scheme (you won't get more than 9 images in memory), but less might be not enough (big images will fill the memory without calling the GC earlier.) Considering the difficulties avoid memory overflow, the only workable approach still seems to have an over-eager GC, that happens much more often than necessary. But as a result the caching effect is very limited. Otherwise you need to change all the parameters in lablgtk. Jacques Garrigue