caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Damien Bobillot <damien.bobillot@m4x.org>
To: Jon Harrop <jon@ffconsultancy.com>
Cc: caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Profiling garbage
Date: Wed, 14 Sep 2005 14:23:56 +0200	[thread overview]
Message-ID: <EEDF0CF3-93BC-4C30-B6F2-DAE56FC6E70F@m4x.org> (raw)
In-Reply-To: <200509140321.43045.jon@ffconsultancy.com>

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]


Jon Harrop wrote :

> I've recently been trying to optimize Presenta. The profiling results
> surprised me. Most of the time was spent in the GC, invoked by
> "<spontaneous>". I assumed this meant that the GC was recycling  
> enormous
> amounts of garbage from the old generation. Had it been recycled  
> from the
> young generation then I assume the calls to the (minor) GC would be  
> invoked
> by the allocating function - is that right?
>
> Anyway, the best way I found to track down the offending function  
> was to write
> lots of extra code to spew out Gc.stat results and look at the  
> amount of data
> being allocated by each function call. Doing this by hand is very  
> tedious, of
> course. So I'm wondering, are there any tools to profile allocation  
> and
> collection on a per function basis for OCaml code? I'm thinking of  
> something
> along the lines of gprof results but showing space rather than time  
> taken.
>
> I managed to find the offending function by hand this time - it was
> retypesetting the entire document every frame, regenerating the  
> scene graph.
> Memoizing it improved the performance of the whole program by an  
> order of
> magnitude. So this is definitely an optimisation trick worth  
> remembering...

You may use GC den-bugging information by adding the following  
commands at the beginning of your code :
     Gc.set { (Gc.get()) with Gc.verbose = 1+2+4+8 };;

This will print a message on stdout every time a minor or major  
collection is done, and some other actions like heap growing.

You may print at any time the current GC statistics (number of  
collections, current heap size, total number of allocated bytes…) with :
     Gc.print_stat stderr;;

It's also possible to tune the GC parameter to reduce frequency of  
minor collections (by increasing the minor heap size for instance)  
and some other things.

For more information, have a look at :
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html

-- 
Damien alias Schmurtz
aim:goim?screenname=schmuuurtz


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2375 bytes --]

      reply	other threads:[~2005-09-14 12:24 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-14  2:21 Jon Harrop
2005-09-14 12:23 ` Damien Bobillot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EEDF0CF3-93BC-4C30-B6F2-DAE56FC6E70F@m4x.org \
    --to=damien.bobillot@m4x.org \
    --cc=caml-list@inria.fr \
    --cc=jon@ffconsultancy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).