From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p07ECLJQ027897 for ; Fri, 7 Jan 2011 15:12:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAE+tJk1CbwQZkWdsb2JhbACkJxYBAgkLCgcRBCC8FwWFTIRrhiI X-IronPort-AV: E=Sophos;i="4.60,289,1291590000"; d="scan'208";a="84626068" Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 07 Jan 2011 15:12:15 +0100 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 9117520AB1 for ; Fri, 7 Jan 2011 09:12:13 -0500 (EST) Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute3.internal (MEProxy); Fri, 07 Jan 2011 09:12:13 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=date:from:to:subject:message-id:mime-version:content-type:in-reply-to; s=smtpout; bh=pwoUzD2Ou7bR0h1MmNmid6Bn9w0=; b=pASXn7oJBDIQhK6JckRW2zEmJDh4tNtsYwGw5RDOnXxJb5mkbHWJNM1Gy8qrQ4uw2MvQwL/ItQRyMt6rWH9wOsY1QwKzvakOO6YGMnK7aSaECHMQ9DVo4+kOclY2RbOwQFD97L9vdAJIGjFEN8IAG1MeUouleGAbY+OvYIJcy0g= X-Sasl-enc: UWSO0yYlpD8ZPqvb2upbxVqbN8bUnZxbrgyCvfvDThay 1294409533 Received: from localhost (user-12hdvta.cable.mindspring.com [69.22.255.170]) by mail.messagingengine.com (Postfix) with ESMTPSA id 368BD4452AC for ; Fri, 7 Jan 2011 09:12:13 -0500 (EST) Date: Fri, 7 Jan 2011 09:14:26 -0500 From: Jim Pryor To: caml users Message-ID: <20110107141426.GF12229@vaio.hsd1.pa.comcast.net> Mail-Followup-To: caml users MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1294326332.17561.3.camel@nyc-qws-062.delacy.com> <7577E373-EB25-4A7E-90C1-30491F27B4F9@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] memory leak in toplevel? or, how to implement sizeof On Thu, Jan 06, 2011 at 10:05:32AM -0500, Pascal Zimmer wrote: > Because the overhead parameter can vary based on which version of OCaml > you are running, what the Gc module does, etc, I usually implement this > kind of measurements in this way: > > # let sizeof maker arg = > let first = Gc.((stat()).minor_words) in > for i = 1 to 1000000 do > ignore (maker arg) > done; > let second = Gc.((stat()).minor_words) in > (second -. first) /. 1e6;; > > # sizeof (fun x -> [x]) 1;; > - : float = 3.000022 > > The overhead gets amortized enough that is becomes negligible (you only > have to rely on the fact that the loop does not do any allocation). Thanks, that's a nice and sensible shortcut. On Fri, Jan 07, 2011 at 01:25:42PM +0100, Damien Doligez wrote: > The overhead is exactly the heap space used by the value returned by > Gc.stat. In your case it is 23 words, not 22. Yes, that's right, the Gc.stat on my machine uses 23 words of heap, and of course we should let OCaml calculate the size for us, because as you say it will differ on different architectures. > > > # sizeof (fun x -> x) 10;; > > - : int * int = (1, 10) > > > > That is, one word for the int. > > The int is not allocated in the heap, so the result should be 0. There's a design choice here: we have to decide whether sizeof counts only the allocated heap space or also the pointer to it. Initially I also found it more natural to count only the allocated heap space, as you're proposing. But then when testing on embedded blocks I talked myself into thinking the other choice worked more smoothly. Looking at it again, though, I think I had just confused myself and you're right, counting only the heap space is best. Thanks for the feedback, both of you. -- Jim Pryor profjim@jimpryor.net