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" > <[EMAIL PROTECTED]> > To: "Kornél Pál" <[EMAIL PROTECTED]>; "Atsushi Eno" <[EMAIL PROTECTED]> > Cc: <mono-devel-list@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" >> <[EMAIL PROTECTED]> >> To: "Kornél Pál" <[EMAIL PROTECTED]>; "Atsushi Eno" >> <[EMAIL PROTECTED]> >> Cc: <mono-devel-list@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@lists.ximian.com >>> http://lists.ximian.com/mailman/listinfo/mono-devel-list >>> >> >> > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list