[Mono-dev] Why do we need separate I18N assemblies?
ClassDevelopment at A-SoftTech.com
Sun Jul 2 13:34:44 EDT 2006
>> 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
>> directly into corelib and the larger and seldom used ones in one or more
>> additional assemblies that could be referenced without reflection and
>> 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,
>> 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.
P.S. All tests done on Athlon 3500+, Mono 1.1.15, XPx64
More information about the Mono-devel-list