[Mono-devel-list] GC/Memory allocation performance

[Paolo Molaro]

On 05/30/03 Varga Zoltan wrote:
>    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.

Yes, we'll need to write specialized functions and call them from the JIT,
though that is not the whole picture.
In those kind of microbenchmarks, a generational GC will always perform
better and the MS GC is also very good at that. In real word code the
difference may be considerably less.
On my system a C program that allocates 8 million objects takes 1.65
seconds and the equivalent mono program (with an empty ctor) takes
2.7 seconds, so most of the overhead is still in libgc (note that
linking libgc statically provides a good improvement: 0.95 secs).
There's also another issue: the microbenchmark is 50% slower when run on
windows than on linux for me, so comparing the numbers we get from mono 
on windows vs the MS runtime gives a worse picture than it really is 
(a willing win32 programmer should be able to find out what the issue is).
I guess that's one more reason for people to switch away from windows:-)

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better