[Mono-list] Poor Mono performance

Nigel Delaney nigel.delaney at outlook.com
Tue Mar 12 18:42:06 UTC 2013

Ah okay, should also read emails more before responding.  Just saw the
multiply versus add difference in the order of operations.  I just have no
idea why you would do so many operations inside the Advance method to effect
a simple change, that still seems very strange.  


From: mono-list-bounces at lists.ximian.com
<mailto:mono-list-bounces at lists.ximian.com>
[mailto:mono-list-bounces at lists.ximian.com] On Behalf Of Olajos, Imre
Sent: Tuesday, March 12, 2013 12:09 PM
To: mono-list at lists.ximian.com <mailto:mono-list at lists.ximian.com> 
Subject: Re: [Mono-list] Poor Mono performance




Of course, yours runs a lot faster, that's because you've substantially
changed the loop: it's not looping through all 10*10*100*100*100 iterations
any more, it only does 10+10+100+100+100 iterations now. You're also no
longer incrementing 'counter' for each iteration. (My real life code does a
lot of object creations and function calls in place of where I put a
counter++ in the do-while loop body of my original code.)




From: Nigel Delaney [via Mono]
[mailto:ml-node+s1490590n4658944h83 at n4.nabble.com] 
Sent: Monday, March 11, 2013 1:14 PM
To: Olajos, Imre
Subject: Re: Poor Mono performance


I played around a bit with this and also noticed a very substantial MS 
versus MONO difference, some notes on this: 

*The biggest performance difference here is not the mono vs. .NET but rather

how the program is written.  Right now the bulk of the code on both Mono and

.NET is spent on the do-while loop, and this is a HUGE waste of repeated 
method calls.  Every increment of an array element involves a method call, 
and I could drop the runtime of the program about two orders of magnitude by

writing a different advance function as shown at the end of this email. 
That function can't really be inlined properly by either MS or mono, and the

runtime goes from about 1.9 seconds on my machine to .01 seconds with this 
change, though the code does the same thing.  If the code you are writing in

practice does look like this, it can be improved a lot by having the called 
method not return until a condition is met, rather than returning, checking 
the condition, and calling again. 

 *Strangely, after the code is changed to accommodate this, mono and MS on 
my test machine appear to have an unbelievably large difference in speed. 
This appears to be "fake" differences due to how the startime variable is 
set and nothing to do with the execution speed of the main method.  If 
starttime is reset inside the method by setting it again after printing it 
to the console, the performance difference disappears.  There still appears 
to be a <2X mono performance penalty when mono is used with a List type, but

with an array for the counters, I seem to get the same results on mono and 

If you try the program below, I would be interested to know if the speed was

equivalent on your machine for mono and .net.  One problem is that it is so 
fast on both now that it is hard to compare. 


PS It would still be nice to have a way to view the emitted assembly code on

windows in mono so could compare with the ms clr. 

//improved program 
using System; 
using System.Collections.Generic; 
namespace SpeedTest 
    class SpeedTest 
        static void Main(string[] args) 
            var totals = new int[] { 10, 10, 100, 100, 100 }; 
            var counters = new int[] { 0, 0, 0, 0, 0 }; ; 
            int counter = 0; 
            //Variable needs to be set again after printing, otherwise 
result is wrong 
            var startTime = DateTime.Now; 
            Console.WriteLine("START TIME: {0}", startTime.ToString()); 
            startTime = DateTime.Now; 
            int total = 1; 
            for(int i=0;i<totals.Length;i++) { 
            Console.WriteLine("Total = {0}", total); 
            Console.WriteLine("Dif= {0}", (DateTime.Now - 
            //just to make sure it doesn't avoid the advance method call 
            var endTime = DateTime.Now; 
            Console.WriteLine("END TIME: {0}", endTime.ToString()); 
            Console.WriteLine("RUN TIME: {0}", (endTime - 
        static void Advance(int[] current, int[] total) 
            for (int index = current.Length - 1; index >= 0; --index) 
                while(current[index] != (total[index] - 1)) 

From: [hidden email] 
[[hidden email]] On Behalf Of Robert Jordan 
[[hidden email]] 
Sent: Monday, March 11, 2013 2:15 PM 
To: [hidden email] 
Subject: Re: [Mono-list] Poor Mono performance 

On 11.03.2013 17:19, Olajos, Imre wrote: 
> Is there anything I can do that would bring their relative performance 
> difference closer to each other (e.g. below 20-25%)? 

So you didn't find the well-hidden "--make-me-as-fast-as-ms" 
switch, did you? :) 

You're comparing MS' 64-bit runtime with a 32-bit Mono w/out LLVM support 
and with a pretty slow GC (under Windows). 

Since Windows isn't Mono's prime-time OS, you may want to try under 64-bit 
Linux (where you can have LLVM and alternative GCs), identify bottlenecks 
and file bugs with appropriate test cases. 


Mono-list maillist  -  [hidden email] 
Mono-list maillist  -  [hidden email] 


If you reply to this email, your message will be added to the discussion


To unsubscribe from Poor Mono performance, click here
MDMw> .
ils%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> NAML 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-list/attachments/20130312/4404429f/attachment.html>

More information about the Mono-list mailing list