String performance boost (Re: [Mono-dev] Patch to boost speedofUnicodeEncoding)

Paolo Molaro lupus at
Mon Mar 20 11:05:06 EST 2006

On 03/17/06 Zac Bowling wrote:
> However when I tested some real world desktop apps (like a little
> winform notepad app I have) and some apps ( forums was
> one big one), I was getting a lot of strings larger then that 4096
> chars. Nearly 15% of all the strings where that large in those apps.
> It's not an accurate number as many strings get copied and counted
> twice in some ways but it is safe to say we work with some large
> strings that slow us down a hair.

All of this is very interesting, but do you have a profile run that
shows memcpy() to be in the hot spots?

> Since string sizes can very so much for different applications, I think
> the best solution is to test where we start to hurt ourselves using
> each string method and each of its operatations (substring, copy, trim,
> etc) and find all the breaking points where each method gets slower
> (unmanaged vs managed, buffer.copyarray, memcpy coping in 16/8/4/2
> chunks etc..). Then we write in with some logic that decides which
> method to use based on the size of the string we are working on.

Having 3 implementations of the same thing is orrible for mainatinance
and code bloat.
As for the cutoff values for managed/unmanaged implementations: they
vary a lot dependning on the architecture and we're not going to insert
lots of arch-specific code in corlib (at least not for small
The way to move forward is:
*) write managed versions of the methods, avoinding icalls when possible
*) benchmark and if we are significantly slower than the icall:
  a) optimize the managed code
  b) enhance the jit so it optimizes the code better

Some very specific and common methods may be implemented in hand-coded
assembly in the jit if really needed (read: after some real world code
shows them as hot spots).


lupus at                                     debian/rules
lupus at                             Monkeys do it better

More information about the Mono-devel-list mailing list