Re: [Caml-list] Re: gc overhead

[Edgar Friendly <thelema314@gmail.com>]

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

On 03/02/2010 06:09 PM, Warren Harris wrote:
>
> On Mar 2, 2010, at 2:03 PM, Sylvain Le Gall wrote:
>>
>> You can have a look at:
>> http://ocamlviz.forge.ocamlcore.org
>>
>> This allow to instrument your code and watch GC activity. I think that
>> with a little a little help on program side, you can be quite precise
>> about GC without using gprof at all. This should also be more
>> lightweight than gprof.
>
> Sylvain,
>
> Thanks! This looks very promising. I'll give it a try.
>
> Warren
>
I'd like to add my personal experience with ocamlviz - it's a great 
program, and has helped me a ton find unexpected performance.  It has 
very good functions for starting and stopping timers that the gui can 
monitor in realtime, and associating these with counts of how many times 
your program reached a certain point can give good understanding of 
function call cost.  It's memory profiler makes a very pretty graph of 
how much memory is in use by your program.  I've also gotten started 
using its ability to watch the live value of ref values to monitor the 
state of the program easier than [eprintf]s, especially monitoring the 
state of many variables at once.  It's very fast and the ability to 
debug over the network has come in handy more than once.

This said, I've wanted to measure GC overhead with it, and found it 
lacking in that regard.  If anyone finds a way to do this, I'm interested.

I've not done much with its tree viewer, and the hashtbl monitor only 
indicated that the Hashtbl.t I was using had an amazingly horrible hash, 
and was filling only 3% of its buckets, and had thousands of entries in 
a few buckets.  I tried to fix the hash, but ended up switching to a Map.

Lastly, the ability to mark in memory certain values and have it count 
the total usage and/or count of those values seems interesting, but gets 
quite slow.  I've not had much luck with it.

Overall, good job.  But is it going to die or stay maintained?
E

[-- Attachment #2: Type: text/html, Size: 2673 bytes --]