From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id A1B06BC57 for ; Wed, 3 Mar 2010 12:11:10 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0BAAvTjUvZSMDdimdsb2JhbACbCxUBAQEKCQwHEQUfvyKEfAQ X-IronPort-AV: E=Sophos;i="4.49,573,1262559600"; d="scan'208";a="45825634" Received: from fmmailgate01.web.de ([217.72.192.221]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 Mar 2010 12:11:07 +0100 Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate01.web.de (Postfix) with ESMTP id 1AF1514A9AAF7; Wed, 3 Mar 2010 12:11:07 +0100 (CET) Received: from [85.216.85.71] (helo=frosties.localdomain) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NmmTq-0000Zz-00; Wed, 03 Mar 2010 12:11:06 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1NmmTq-00054d-FT; Wed, 03 Mar 2010 12:11:06 +0100 From: Goswin von Brederlow To: Warren Harris Cc: OCaml Subject: Re: [Caml-list] gc overhead References: <37150F07-8902-464A-9A0E-44A0C424C87B@gmail.com> Date: Wed, 03 Mar 2010 12:11:06 +0100 In-Reply-To: <37150F07-8902-464A-9A0E-44A0C424C87B@gmail.com> (Warren Harris's message of "Sun, 28 Feb 2010 16:16:03 -0800") Message-ID: <87bpf5lkxh.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/ehHRJKcGnPd3ckm+cUXxJzrMMlz1nyGwfPVmd ZVg+8VK5szlKZKUopSybHqfFPQ+fyQuVcRELVTbFYqhpew7xBH xtrEEzI0E= X-Spam: no; 0.00; implements:01 compaction:01 warren:98 warren:98 increments:98 mfg:98 garbage:01 caml-list:01 short:01 writes:01 cached:02 objects:02 objects:02 gprof:03 overhead:04 Warren Harris writes: > I would like to determine what percentage of my application's cpu time > is spent in the garbage collector (for tuning purposes, but also just > to monitor the overhead). Is there any way to obtain this information > short of using gprof? Additional information provided by Gc.stat would > be ideal, or perhaps a Gc.alarm that was called at the beginning of > the gc cycle, but neither of these seem to exist. > > Warren In my code I have a cache structure that implements a last-recently-used ordering of cached objects. As objects are used the list grows an every now and then I have to shrink it. It would be real nice if I could shrink it exactly before evrey GC major cycle or compaction. I also saw that Gc.alarm is called AFTER each GC cycle. But maybe that doesn't matter as after a cycle is before a cycle. With the major cycle being done in increments the next cycle probably starts right after the last one finished compared to the time the cycle takes overall. MfG Goswin