[Mono-dev] Why do we need separate I18N assemblies?

[Andreas Nahr]

Hello,

>> I think it would be worth it to try to remove the reflection overhead,
>> because it is not just taking some time but also quite some amount of
>> additional memory. Personally I would recommend to put the small 
>> encodings
>> directly into corelib and the larger and seldom used ones in one or more
>> additional assemblies that could be referenced without reflection and 
>> simply
>> be deleted when not needed.
>
> As you point out in one of your emails, I think it is worth fixing the
> code that triggers the culture-dependent string compares in our class
> libraries, they are likely not needed.

Well, I guess that is more of a sideeffect found in the process looking at 
it. I just did some simple measuring and at least in CPU-Performance the 
Globalization stuff is completely negegible (beyond of what the timer of 
mono --profile can measure). The problem here is more that this code could 
fail on certain locales (in the examples I wrote my guess would be that the 
first one would not work on a turkish locale).

> As for not using reflection, am afraid that even if we removed the use
> of Reflection for the encodings, reflection will end up being triggered
> anyways as too much code in Mono (in addition to standard .NET
> practices) will trigger the reflection bits to be loaded.

However this could still save most of the runtime initialization cost, which 
is usually even more than the JIT-Time.

> Integrating the most commonly used encodings into corlib sounds like a
> good idea, someone would have to prototype it and measure it.
>
>
>> The overhead actually comes mostly from two places:
>> a) I18N
>> b) Globalisation
>>
>> b is triggered because of String handling mistakes within corelib, 
>> however
>> the biggest share in runtime is I18N (see textfile - 78 ms out of 93 ms
>> total app time).
>
> Thanks for looking at the problematic sources.    I like the idea of
> fixing these issues, but am not sure that they will have a real effect
> on applications.

I did some more simple measuring and would expect a nice potential for 
improvement (obviously mostly for small CMD-Apps):
1) I ran mcs.exe --help to display the help of mcs. Virtually 100% of the 
runtime were spent for the Initialization of I18N (obviously this means that 
mono cannot do more detailed measuring with --profile, because mcs should 
need some cycles, too ;)
2) Ran mcs.exe for compiling a simple application. Nearly 25% of the entire 
runtime were spent only for *Initialization* of I18N.

> The globalization code will likely be used shortly after, at least for
> any non-trivial program.

You're surely right on this one. Also the Globalization overhead is tiny 
compared with I18N.

Greetings
Andreas

P.S. All tests done on Athlon 3500+, Mono 1.1.15, XPx64