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