[Mono-dev] substantial performance regression between 2.10 and 2.6 or impl diff?

Rodrigo Kumpera kumpera at gmail.com
Sat Aug 27 19:09:04 EDT 2011

There are a few points to note here.

Linux with the default GC is much faster than OSX since the laster can't use
fast object allocation.

OSX 2.6 shipped with default parallel mark enabled on OSX, but it was later
disabled due to bugs in boehm.

Given no one is actively working on boehm, this was the best option. My
suggestion is that you try using the new GC
try running 2.10 with --gc=sgen. Performance will be substantially better
for your test.

On Sat, Aug 27, 2011 at 2:27 PM, Jonathan Shore <jonathan.shore at gmail.com>wrote:

> Hi,
> I was doing some benchmarks of struct vs class based creation (I have an
> application that will generate millions of small objects).   I was doing the
> tests in a ubuntu 11.4 VM on my mac pro and found the following:
> mono *2.6.7 was 4x faster* on my linux VM *than 2.10.4 *running on OSX
> (same machine)
> I don't know whether this may be because of one of the following:
> - performance in 2.10.4 regressed vs 2.6.7
> - mono JIT implementation for OSX has a completely different JiT codebase
> and does not perform
> - difference in GC (only relevant for second part of the test)
> Note that I tried this with separate compilations with mcs -optimize+  on
> both environments as well as running the same exe on both.
> I can live with slower performance on OSX, but want to make sure that linux
> and windows versions of mono 2.10.x have the performance of 2.6.7 or better.
> Can someone clue me in?   I've included the simple test code with this
> posting.
> Thanks
> Jonathan
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20110827/cc73352b/attachment.html 

More information about the Mono-devel-list mailing list