profile not showing it all?

Simon Marlow simonmar at
Mon Sep 12 07:18:50 EDT 2005

On 09 September 2005 15:58, Niels wrote:

> Bulat Ziganshin wrote:
>> i don't know what value shows the -xc oprion, but memory usage in
>> ghc-compiled program are increased because by default used "copying"
>> garbage collection algorithm. using option "+RTS -c" will
>> significantly reduce memory usage, which will make program faster if
>> it currently needs swapping. you can also force, for example, using
>> of compacting algorithm when memory usage grows more than 200 mb with
>> options "+RTS -M1G -c20". see "4.14.2. RTS options to control the
>> garbage collector" in ghc docs for details
> running the profilingbinary (that was compiled with -prof -auto-all)
> with the -c option resulted in;
> top: showing a max of 161mb memory usage
> profiled-graph: showing a peak at a little more than 80mb
> i guess these results are more or less normal? It does however mean
> that my datastructures are pretty harsh on the garbage collector,
> doesnt it? 

The difference between the residency displayed by the heap profiler and
the actual memory residency can be attributed to several factors (some
of which have already been mentioned, I thought I'd list them for

  - overhead of profiling itself, which currently runs at 2 extra
    words per heap object.  At a guess, that probably results in
    about a 30% overhead.

  - generational garbage collection.  A major GC in the standard
    copying collector will usually require 3L bytes of memory, where
    L is the amount of live data.  This is because by default (see the
    +RTS -F option) we allow the old generation to grow to twice its
    size (2L) before collecting it, and we require additionally L bytes
    to copy the live data into.  When using compacting collection, this
    is reduced to 2L, and can further be reduced by tweaking the -F
    option.  Additionally the allocation area (generation 0) takes 512Kb
    by default.

  - The stack isn't counted in the heap profile by default.  See the
    +RTS -xt option.

  - The program text itself, the C stack, any non-heap data (eg. data 
    allocated by foreign libraries, and data allocated by the RTS), and
    mmap()'d memory are not counted in the heap profile.


More information about the Glasgow-haskell-users mailing list