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 8AE5FBB83 for ; Tue, 15 Aug 2006 01:30:08 +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 k7ENU8Z3007405 for ; Tue, 15 Aug 2006 01:30:08 +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 BAA21895 for ; Tue, 15 Aug 2006 01:30:07 +0200 (MET DST) Received: from mz3.forethought.net (mzpi5.forethought.net [216.241.36.14]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k7ENU6wB007391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 15 Aug 2006 01:30:07 +0200 Received: from [216.241.35.41] (helo=[10.0.0.2]) by mz3.forethought.net with esmtp (Exim 4.51) id 1GClsi-0008SZ-Ad for caml-list@inria.fr; Mon, 14 Aug 2006 17:30:05 -0600 Message-ID: <44E10783.5000605@gushee.net> Date: Mon, 14 Aug 2006 17:30:11 -0600 From: Matt Gushee User-Agent: Thunderbird 1.5.0.5 (X11/20060729) MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: [Caml-list] Weak hashtables & aggressive caching References: <44E08F95.2070105@gushee.net> <20060815.062335.55488138.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20060815.062335.55488138.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44E10780.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 44E1077E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; hashtables:01 caching:01 allocations:01 lablgtk:01 invokes:01 garbage:01 wrote:01 caml-list:01 explicitly:01 data:02 structures:02 external:02 garrigue:03 jacques:03 weak:04 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 Jacques Garrigue wrote: > 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 wasn't planning to trigger the GC explicitly. My thought was simply to stop preloading before GC begins (or at least *when* GC begins). > 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. You mean that LablGTK directly invokes the garbage collector after 10 images. That's not much (unless, of course, they are big images). Sounds like it's a lot of trouble for a small benefit. -- Matt Gushee : Bantam - lightweight file manager : matt.gushee.net/software/bantam/ : : RASCL's A Simple Configuration Language : matt.gushee.net/rascl/ :