Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Average cost of the OCaml GC
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2010-11-12 (17:27)
From: Jianzhou Zhao <jianzhou@s...>
Subject: Re: [Caml-list] Average cost of the OCaml GC
On Thu, Nov 11, 2010 at 3:11 PM, Goswin von Brederlow <> wrote:
> Jianzhou Zhao <> writes:
>> On Thu, Nov 11, 2010 at 4:08 AM, Goswin von Brederlow <> wrote:
>>> Jianzhou Zhao <> writes:
>>>> Hi,
>>>> What is the average cost of the OCaml GC? I have a program that calls
>>>> 'mark_slice' in 57% of the total execution time, and calls
>>>> 'sweep_slice' in 21% of the total time, reported by Callgrind, which
>>>> is a profiling tool in Valgrind. 57% and 21% are the 'self cost' ---
>>>> the cost of the function itself ('Self Cost'), rather than the cost
>>>> including all called functions ('Inclusive Cost'). I guess
>>>> 'mark_slice'  and  'sweep_slice'  are functions from OCaml GC. Are
>>>> these numbers normal?
>>> Those numbers sound rather high to me.
>>>> My program calls both OCaml and C, which passes around C data types in
>>>> between. I also doubt if I defined the interface in an 'unefficient'
>>>> way that slows down the GC. Are there any rules in mind to make GC
>>>> work more efficiently?
>>> You can tune some of the GC parameters to suit your use case.
>>> Do you allocate custom types from C? In caml_alloc_custom(ops, size,
>>> used, max) the used and max do influence the GC how often to run.
>> Yes. The code uses caml_alloc_custom to create a lot of small objects
>> (less then 8 bytes) frequently. The used and max are set to be
>> default, 0 and 1. The manual says
>> /////////////////////
>> If your finalized blocks contain no pointers to out-of-heap resources,
>> or if the previous discussion made little sense to you, just take used
>> = 0 and max = 1. But if you later find that the finalization functions
>> are not called “often enough”, consider increasing the used / max
>> ratio.
>> //////////////////////
>> Does this mean the default used and max let GC do finalization 'as
>> slow as possible'? This does not seem to be the case if the costs 57%
>> and 20% are too high.
> I think 0/1 gives you the least amount of GC runs.
>>> If you set them wrong you might trigger the GC too often.
>> In which case could they be set 'wrong'? For example, if 'used' is not
>> equal to the real amount of allocated data; or is there a range of
>> 'max' given a used?
> A used = 1000000 would be wrong here. Your 0/1 setting look fine to me.

Do we still have other methods to debug such problems? Is it possible
to know when and where GC runs, say, the number of times GC works
after a particular usr-defined function? If this is possible, I was
wondering if we can see which function in my code behave wrong.

> MfG
>        Goswin