[Mono-dev] Why do we need separate I18N assemblies?
Sebastien Pouliot
sebastien.pouliot at gmail.com
Sat Jul 1 11:34:54 EDT 2006
Hello Andreas,
Thanks for your quick review and please fill bugs for the issues you
find.
P.S. I encourage you write a Gendarme rule to check for this behavior
(which we can turned on Mono BCL). It's probably faster than doing the
review itself, won't miss any case and can be reused by anyone.
On Sat, 2006-07-01 at 11:10 +0200, 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)
It's (mostly) a copy of System's Uri which some required changes to be
used by corlib's security classes.
> 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.
Please open a bug for them.
> ----- 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
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Sebastien Pouliot <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/
More information about the Mono-devel-list
mailing list