[Mono-devel-list] Mono strings 10x slower than .NET

[William Garrison]

One other thing that I just realized that might be worth knowing:

String.compare(string,string,true) <-- case-sensitive
is 3x slower than
String.compare(string,string,false) <-- case-insensitive

Why would the case-insensitive compare be _faster_?  Sorry, I don't mean 
to beat a dead horse.  I just noticed this and thought it was 
particularly odd.

Paolo Molaro wrote:

> On 06/05/04 William Garrison wrote:
> 
>>I just compiled my first application in Mono.  It's a code highlighter & 
>>diff tool.  It runs great under Mono, except that it runs 10 times 
>>slower than under .NET!  .NET runs my standard test case in 2-3 seconds, 
>>while Mono takes 19-23 seconds.  The times are the same on both Windows 
>>and Linux (RH9) and with the EXE file compiled under both .NET and Mono.
>>
>>I used the --profile option, and the problem appears to be 
>>System.String::Compare.  My code is unoptimized, and does LOTS of string 
>>compares.  When profiling, the code took 32 seconds to run, with 24 
>>seconds being the string compares.
> 
> [...]
> 
>>After all that, I want to know:
>>1) What is the current status of string performance under Mono?
> 
> 
> When using culture-sensitive compares it's quite slow, especially if
> mono was compiled with ICU support (collation and other issues add a lot
> of overhead).
> Do you really need the culture-sensitive Compare? CompareOrdinal
> should be slightly faster, especially with mono build without ICU support.
> Or, you may want to use String.Equals() which is tons faster and
> probably what you need to do in a diff-like tool anyway.
> 
> 
>>2) What can I give someone to help demonstrate or track down the problem?
> 
> 
> We know about the compare slowness (I think we discussed it at the
> Boston meeting, too), but nobody had the time yet to through away the
> current ICU/Compare code and rewrite it. See if using Equals() solves
> the issue for you, in the meantime.
> 
> lupus
>