- 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. top also shows 161mb for the non-profiling binary (the same as the
Simon Marlow wrote: profiling binary). This strikes me as odd, because the profiling binary *should* take more memory (because of all the reasons mentioned in this thread).
- 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. with -c, top records 149mb max (it just grows more gradually) and without -c, top records 161 max.
I used the -B setting to sound a bell at the beginning of a major GC, so i could relate the memory growth showing up in top to the start of a GC. However, im not hearing anything (also -t, which should show GC stats after running the program, is not showing anything). Does this mean there was no GC ? Niels.