From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id D0808BC48 for ; Mon, 11 Apr 2005 16:22:29 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j3BEMTJv023076 for ; Mon, 11 Apr 2005 16:22:29 +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 QAA02046 for ; Mon, 11 Apr 2005 16:22:29 +0200 (MET DST) Received: from [IPv6:::1] (yquem.inria.fr [128.93.8.37]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j3BEMSrL023073 for ; Mon, 11 Apr 2005 16:22:29 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <424ABFAE.7080309@barettadeit.com> References: <424A65C4.2080507@barettadeit.com> <200503301303.46742.jon@ffconsultancy.com> <424A9CCA.7030204@barettadeit.com> <200503301509.01571.A.S.Usov@kvi.nl> <874qetdypa.fsf@qrnik.zagroda> <424ABFAE.7080309@barettadeit.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Damien Doligez Subject: Re: [Caml-list] Impact of GC on memoized algorithm Date: Mon, 11 Apr 2005 16:22:57 +0200 To: caml users X-Mailer: Apple Mail (2.619.2) X-Miltered: at nez-perce with ID 425A8825.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 425A8824.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; damien:01 damien:01 caml-list:01 memoized:01 baretta:01 pairs:01 heap:01 heap:01 wrote:01 doligez:01 doligez:01 algorithm:01 algorithm:01 linear:02 linear:02 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Mar 30, 2005, at 17:03, Alex Baretta wrote: > And, then again, how does the Gc.full_major scale as the "cache" for > the algorithm fills up with millions of key-value pairs? Is the GC > linear on the number of *reclaimed* blocks, or is it linear in the > *total* number of allocated blocks? Why did you have to ask this question on the first day of my vacation? :-) Anyway, the total cost of a major collection cycle is proportional to the heap size, but the frequency of these cycles is inversely proportional to the heap size. Hence, under reasonable assumptions, average GC cost is constant for each word that you allocate. Of course, the picture becomes entirely different if you have lots of explicit calls to Gc.major, Gc.full_major, or Gc.compact. -- Damien