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
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
