Profiling garbage

Profiling garbage

[Jon Harrop]

I've recently been trying to optimise 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...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Profiling garbage

[Damien Bobillot]

[-- 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 --]