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 DD9C0BB81 for ; Fri, 14 Oct 2005 12:49:41 +0200 (CEST) Received: from decis.be ([194.78.219.157]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j9EAnffG028255 for ; Fri, 14 Oct 2005 12:49:41 +0200 Received: from decis.be by decis.be (MDaemon.PRO.v8.1.3.R) with ESMTP id md50000333542.msg for ; Fri, 14 Oct 2005 12:50:58 +0200 Message-ID: <434F8DCB.550F88CB@decis.be> Date: Fri, 14 Oct 2005 10:51:55 +0000 From: Frederic van der Plancke Organization: Decis X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr-BE,fr MIME-Version: 1.0 To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Memory usage/ garbage collection question References: <20051014094948.GA11039@furbychan.cocan.org> <20051014102749.GA15524@furbychan.cocan.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: fplancke@decis.be X-MDRemoteIP: 192.168.0.20 X-Return-Path: fvdp@decis.be X-MDaemon-Deliver-To: caml-list@yquem.inria.fr Reply-To: fvdp@decis.be X-Miltered: at concorde with ID 434F8D45.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; plancke:01 caml-list:01 garbage:01 iterating:01 garbage:01 iteration:01 ocamlopt:01 iter:01 compiler:01 iter:01 compiler:01 optimise:01 ...:98 unnamed:98 ...:98 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 Richard Jones wrote: > > On Fri, Oct 14, 2005 at 04:58:59AM -0500, Seth J. Fogarty wrote: > > I do not see why iterating through a list that consumed a lot of > > memory should (innately) cause you to thrash. What is thrashing? > > access to the disk? Garbage collection? > > That's where I'm not really sure, except that it is observably > thrashing. Since it's a simple iteration, I guess that would > implicate the GC? > > > No, because you have bound rows to a name. Now, I believe if rows is > > returned by a function, and is NOT bound by name in that function, it > > can be garbage collected. I.E. > > Ah OK ... I'm interested though: why does binding a value to a name > cause problems? Surely at this level (ocamlopt generated code) there > ought to be no difference between a named value and an unnamed one? > > Rich. Perhaps the problem is not the name, but the fact that when you write List.iter f rows the compiler isn't going to go great lengths in optimizing out the reference to rows before the call to List.iter, since the optimisation probably isn't free and the compiler (and compiler writers) don't know in advance how worthwhile it would be. If the call to List.iter was a tail call the compiler would probably be forced to optimise rows out. Hence my 0.02 cents worth untested idea: you might try and use tail call optimisation to get rid of that reference. say let do_work () = let rows = ... in List.iter (...) rows Frédéric