profile not showing it all?
Simon Marlow
simonmar at microsoft.com
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
completeness):
- 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.
Cheers,
Simon
More information about the Glasgow-haskell-users
mailing list