[Caml-list] Re: gc overhead

2010-03-03 Thread Sylvain Le Gall
Hello,

On 03-03-2010, Edgar Friendly thelema...@gmail.com wrote:
 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

 Thanks! This looks very promising. I'll give it a try.


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


Well, I hope it will stay maintained. At least source code, bugs and
release on the forge will stay there for a long time (I can make promise
on this part). And whenever current developpers become inactive,
OCamlCore.org administrators can move ownership to other (with notice to
current owner, of course):
http://www.ocamlcore.org/philosophy/ (point 4)

But anyway, this kind of tool is targeted at debugging on the first
place. It is not a mandatory piece of a software/library. You can lie
without it, when you have finished your job debugging/profiling your
program.

So I would say that long term maintainance should not bother user for
now. It is actually something that is lightweight and that works. To my
mind this is enough to consider using it. 

If a lot of people start using it, it is highly probable that it will
stay maintained.

Regards
Sylvain Le Gall

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


[Caml-list] Re: gc overhead

2010-03-02 Thread Sylvain Le Gall
On 01-03-2010, Warren Harris warrensomeb...@gmail.com wrote:
 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.


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.

Regards,
Sylvain Le Gall

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


Re: [Caml-list] Re: gc overhead

2010-03-02 Thread Warren Harris


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

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


Re: [Caml-list] Re: gc overhead

2010-03-02 Thread Edgar Friendly

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
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs