[Mono-devel-list] Mono strings 10x slower than .NET
monodevlist at mobydisk.com
Sun Jun 6 11:32:42 EDT 2004
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
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.
More information about the Mono-devel-list