[Mono-dev] Why do we need separate I18N assemblies?
Atsushi Eno
atsushi at ximian.com
Sat Jul 1 07:57:42 EDT 2006
Don't start new topic from an existing thread, especially keeping
irrelevant people CCed. I'm very close to have new spam list entry.
Why not just enter a bug on bugzilla with a patch to wait for
proper people to review it?
Atsushi Eno
Andreas Nahr wrote:
> I had a few minutes and checked through corelib:
>
> In AppDomainSetup:
> private static string GetAppBase(string appBase)
> {
> if (appBase == null)
> {
> return null;
> }
> if ((appBase.Length >= 8) && appBase.ToLower().StartsWith("file://"))
> {
> .......}
> This should most likely be:
> if ((appBase.Length >= 8) &&
> appBase.ToLowerInvariant().StartsWith("file://"))
>
>
> In Module:
> private static bool filter_by_type_name_ignore_case(Type m, object
> filterCriteria)
> {
> string text1 = (string) filterCriteria;
> if (text1.EndsWith("*"))
> {
> return m.Name.ToLower().StartsWith(text1.Substring(0,
> text1.Length - 1).ToLower());
> }
> return (string.Compare(m.Name, text1, true) == 0);
> }
> These .ToLower() are most likely incorrect, too.
> Others are: RemotingConfiguration.SetCustomErrorsMode(string) and
> Microsoft.Win32.UnixRegistryApi.ToUnix(String)
>
> Also lots of stuff in Mono.Security.Uri ist cultural-aware, but probably
> shouldn't be (in fact it's pretty much mixed there between cultural
> aware, not-aware and usage of InvariantCulture)
>
> System.Security.Site.UrlToSite ist most likely wrong, too.
>
> Several other classes in Mono.Security are actually semantically
> correct, but make unneccessary use of the Globalization classes and
> through that produce additional unneeded overhead.
>
> ----- Original Message ----- From: "Andreas Nahr"
> <ClassDevelopment at A-SoftTech.com>
> To: "Kornél Pál" <kornelpal at gmail.com>; "Atsushi Eno" <atsushi at ximian.com>
> Cc: <mono-devel-list at lists.ximian.com>
> Sent: Saturday, July 01, 2006 12:43 AM
> Subject: Re: [Mono-dev] Why do we need separate I18N assemblies?
>
>
> b meant Option b) from above - the Globalization.
>
> If you look at the profile you will see that a simple Console.WriteLine
> ("A") results in the usage/compilation of the Globalization classes.
> This is
> very likely from a bug in the code like comparing two non-cultural-aware
> strings (are there any cultural-aware string in corelib anyway?) in a
> cultural-aware way like this:
> if (String1.ToLower () == String2.ToLower ())
>
>> By the way what do you exactly mean on "b is triggered because of String
>> handling mistakes within corelib"?
>>
>> Kornél
>>
>> ----- Original Message ----- From: "Andreas Nahr"
>> <ClassDevelopment at A-SoftTech.com>
>> To: "Kornél Pál" <kornelpal at gmail.com>; "Atsushi Eno"
>> <atsushi at ximian.com>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 30, 2006 10:26 PM
>> Subject: Re: [Mono-dev] Why do we need separate I18N assemblies?
>>
>>
>>> Hi,
>>>
>>> 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.
>>> I did some simple testing on the potential benefits:
>>> The basic overhead of a Mono Application is a little bit below this:
>>> -----------------------------------------------------------------
>>> Mono Jit statistics
>>> Compiled methods: 35
>>> Methods from AOT: 0
>>> Methods cache lookup: 12
>>> Method trampolines: 868
>>> Basic blocks: 196
>>> Max basic blocks: 14
>>> Allocated vars: 141
>>> Analyze stack repeat: 0
>>> Compiled CIL code size: 1594
>>> Native code size: 5095
>>> Max code size ratio: 32,00 (Object::.ctor)
>>> Biggest method: 1126 (Hashtable::.cctor)
>>> Code reallocs: 3
>>> Allocated code size: 5095
>>> Inlineable methods: 0
>>> Inlined methods: 0
>>>
>>> Created object count: 51
>>> Initialized classes: 53
>>> Used classes: 30
>>> Static data size: 96
>>> VTable data size: 5160
>>>
>>> Generic instances: 0
>>> Initialized classes: 0
>>> Inflated methods: 0 / 0
>>> Inflated types: 0
>>> Generics metadata size: 0
>>> Total time spent compiling 35 methods (sec): 0
>>> -----------------------------------------------------------------
>>> if you do a single
>>> Console.WriteLine ("Test");
>>> It becomes:
>>> -----------------------------------------------------------------
>>> Test
>>> Mono Jit statistics
>>> Compiled methods: 466
>>> Methods from AOT: 0
>>> Methods cache lookup: 511
>>> Method trampolines: 3333
>>> Basic blocks: 3939
>>> Max basic blocks: 237
>>> Allocated vars: 3102
>>> Analyze stack repeat: 0
>>> Compiled CIL code size: 40443
>>> Native code size: 93100
>>> Max code size ratio: 32,00 (Object::.ctor)
>>> Biggest method: 4930 (SimpleCollator::CompareInternal)
>>> Code reallocs: 40
>>> Allocated code size: 93100
>>> Inlineable methods: 0
>>> Inlined methods: 5
>>>
>>> Created object count: 1800
>>> Initialized classes: 235
>>> Used classes: 153
>>> Static data size: 510
>>> VTable data size: 24312
>>>
>>> Generic instances: 0
>>> Initialized classes: 0
>>> Inflated methods: 0 / 0
>>> Inflated types: 0
>>> Generics metadata size: 0
>>> Total time spent compiling 466 methods (sec): 0,0625
>>> Slowest method to compile (sec): 0,01563: I18N.Common.Handlers::.cctor()
>>> -----------------------------------------------------------------
>>>
>>> So this means you have about 20 times as much Native Code Size, need
>>> 150-200
>>> msec additional time (See attached textfile for JITTime+Runtime, run
>>> on a
>>> 3500+ Athlon) and more than 100kb additional memory. Moreover the GC has
>>> to
>>> manage/kill 1800! Objects already, with no single line of Application
>>> code
>>> run yet.
>>>
>>> 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).
>>> In terms of memory it is more complicated to estimate, but from looking
>>> at
>>> the profile one could assume that there are also big potential
>>> optimizations.
>>>
>>> mfg
>>> Andreas
>>>
>>>
>>>> I once dreamed to change encoding implementation like you but
>>>> I noticed that it helps few people other than my personal
>>>> satisfaction and spends too much time just for such a niche
>>>> (at least for me).
>>>>
>>>> When you split conversion map data from I18N.*.dll which is mostly
>>>> extraneous for people who don't use those them, feel free to try
>>>> merging it into mscorlib. Otherwise, I don't like your idea.
>>>
>>> Originally I was thinking of simply moving Encoding classes to corlib
>>> but
>>> you and Jonathan are right that there are cases when it has
>>> advantages if
>>> such large data can be excluded.
>>>
>>> But you are right this would need a lot of time...
>>>
>>>> Why do you quote Microsoft mscorlib size here? It is far from
>>>> something to do with it. Stop making misleading. To my understanding
>>>> they have different files for encoding maps (*.nlp).
>>>
>>> I just tried to glorify the size of our mscorlib.:) If we add the
>>> size of
>>> I18N assemblies to the size of our mscorlib our is sill smaller than
>>> Microsoft's one. (And you are right that it has external dependencies so
>>> the
>>> difference may be even more.) As long as our mscorlib can do the same as
>>> their this only means that ours is better and nothing more.:)
>>>
>>>> "Mono should be MS.NET compatible" is simply wrong as usual.
>>>> We have broader supported environment which requires different
>>>> thinking.
>>>
>>>> From http://www.mono-project.com/FAQ:_General:
>>> "Its objective is to enable UNIX developers to build and deploy
>>> cross-platform .NET Applications."
>>>
>>> And note that this is why I like Mono.:) This goal cannot be achieved
>>> without MS.NET compatibility. Of course I don't mean compatiblitiy at
>>> any
>>> costs. Or for example I don't like the bug compatibility at any cost
>>> policy
>>> of MWF altough I admit that it helps run GUI applications that often
>>> relay
>>> on weird SWF behaviours.
>>>
>>> Kornél
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>
>>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
More information about the Mono-devel-list
mailing list