Re: [Caml-list] Optimizing garbage collection

[Eray Ozkural <examachine@gmail.com>]

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

The program I am testing it on is basically a DFS algorithm so it doesn't
use much heap memory really. Just a lot of transient objects.

Looking at the top the RSIZE looks to be not over 11M under OSX.

Yes, the default minor heap size was indeed too low, I've been trying to set
it to a higher value, now testing with the OCAMLRUNPARAM settings you
recommended. It did result in some speedup, but not an awful lot, it's
important to profile it as you say.

Best,

On Fri, Nov 19, 2010 at 4:54 PM, Michael Ekstrand <michael@elehack.net>wrote:

> On 11/18/2010 09:51 AM, Eray Ozkural wrote:
> > A program I wrote constructs a lot of small lists, and strings and
> > discards them. It's a search algorithm. I profiled this code and saw
> > that garbage collection takes significant time.
> >
> > In C++, we can write custom allocators to optimize the data structures
> > that cause such slowdowns. Any recommended strategies in ocaml?
>
> The OCaml garbage collector exposes a variety of tuning parameters
> through the Gc module[1] and the OCAMLRUNPARAM environment variable[2].
>  I would tweak those.  In particular, I would recommend increasing the
> minor heap size so that more of your data can be quickly discarded.  You
> can also increase the space overhead, thereby causing the GC to be less
> aggressive at the expense of higher memory usage/more waste.  Lastly, I
> often increase the heap increment to allow memory to allow the heap to
> expand more quickly, but I do not know if that will help in your case or
> not.  I have documented my practices more thoroughly at my blog[3].
>
> As I see it, the biggest gains will be by tuning your code and your
> minor heap size so that ephemeral structures never hit the major heap.
> My rule of thumb is that one "work unit", if you have such a concept,
> should fit in the minor heap.  Collecting dead structures from the minor
> heap is fast; moving a structure to the major heap only to have it be
> unreachable by the next GC cycle can cause substantial GC thrashing.
>
> You're on to a good start, though, by measuring.  I use gprof heavily as
> I tweak my code's performance.
>
> - Michael
>
> 1. http://caml.inria.fr/pub/docs/manual-ocaml/libref/Gc.html
> 2. http://caml.inria.fr/pub/docs/manual-ocaml/manual024.html#toc96
> 3. http://elehack.net/michael/blog/2010/06/ocaml-memory-tuning
>
> _______________________________________________
> 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
>



-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

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