AW: [Mono-devel-list] GC/Memory allocation performance
joergr at voelcker.com
Fri May 30 09:32:53 EDT 2003
I think the garbage collector should be working in all cases.
So a special version isn't the right direction?
Maybe this performance difference depends more on the garbage
collector implementation? As I understand it (very basic understanding ;-))
in MS's implementation memory allocation is as simple as incrementing
the pointer to the next free memory block by the amount of allocated
memory. During collection all used blocks are shifted to avoid memory
fragmentation. This may speed up allocation but pointers doesn't stay
constant during runtime.
How's Boehm's GC working? Maybe the fragmentation slows down memory
> -----Ursprüngliche Nachricht-----
> Von: Varga Zoltan [mailto:vargaz at freemail.hu]
> Gesendet: Freitag, 30. Mai 2003 15:08
> An: Jörg Rosenkranz
> Cc: mono-devel-list at lists.ximian.com
> Betreff: Re: [Mono-devel-list] GC/Memory allocation performance
> The current allocation path is not very optimized under
> mono. It involves the following:
> - A call to the icall wrapper for mono_object_new_specific.
> - A call to mono_object_new_specific
> - A call to mono_object_new_alloc_specific
> - A call to GC_MALLOC
> - A call to mono_profiler_allocation
> + a few comparisons etc.
> It would be easy to create an optimized version for the
> common case (no profiler, no remoting etc.). I could do this
> if there is interest.
More information about the Mono-devel-list