From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 24E9CBC6C for ; Wed, 4 Jul 2007 17:57:52 +0200 (CEST) Received: from bsd4.nyct.net (mail-out8.nyct.net [216.139.141.8]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l64Fvo0k018525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Jul 2007 17:57:51 +0200 Received: from [192.168.42.2] (adsl-216-139-154-52.nyct.net [216.139.154.52]) by bsd4.nyct.net (8.13.4/8.13.4) with ESMTP id l64FvioF062601; Wed, 4 Jul 2007 11:57:45 -0400 (EDT) (envelope-from bhurt@spnz.org) Date: Wed, 4 Jul 2007 12:05:44 -0400 (EDT) From: Brian Hurt X-X-Sender: bhurt@localhost To: Joel Reymont Cc: "Markus E.L." , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Which function is consing? In-Reply-To: <1E47C897-547E-4B65-8DB8-46228F438C1A@gmail.com> Message-ID: References: <90BAEAF7-0710-44A3-BB2C-5075A2619371@gmail.com> <1E47C897-547E-4B65-8DB8-46228F438C1A@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Miltered: at concorde with ID 468BC37E.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; allocates:01 allocations:01 pointer:01 ocaml:01 haskell:01 ocaml:01 allocating:01 ocaml's:01 allocating:01 2007,:98 garbage:01 garbage:01 wrote:01 caml-list:01 functions:01 On Wed, 4 Jul 2007, Joel Reymont wrote: > What I would like to find out is how much memory each function allocates. I > would like to minimize memory allocations as they put pressure on the garbage > collector. Are you trying to track down a specific performance problem, or just trying to avoid allocation in general? If it's the former, I've had good luck just hand analyzing functions. Once you know the boxing rules, each block allocated in memory has one tag word associated with it. So if I see "x :: lst" in my code, I know that just allocated 3 words- a tag word for the list block, plus a value and a next pointer. And so on. One of the nice things about Ocaml vr.s Haskell is that this sort of analysis is much easier to do in Ocaml. If you're just trying to reduce memory allocation in general, my advice is to not bother, unless you have evidence that 1) performance isn't acceptable, 2) higher level optimizations (for example, replacing O(N^2) operations with O(N log N) operations) either cannot be applied or would be ineffective, and 3) garbage collection costs from excessive allocation is the problem. One comment I will make: it's not unusual for C/C++ programs to spend considerable amount of time allocating and deallocating objects as well, see: ftp://ftp.cs.colorado.edu/pub/techreports/zorn/CU-CS-665-93.ps.Z And note that this study does not include any overhead of deciding if an object is freeable, which Ocaml's GC does as well. C/C++ allocate and deallocate a heck of a lot less, but the cost of allocating and deallocating is a heck of a lot higher. The difference is that in Ocaml, all of these costs are reported as one big number- "hey, you're spending 30% of your time in GC!" While if you were spending 30% of your time in destructors deciding which objects can be freed yet or not, since that time is spread over a bunch of different functions, it's much less obvious. Brian