Re: [Mono-dev] Why do we need separate I18N assemblies?
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:
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:
> 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:
>> 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
Re: [Mono-dev] Why do we need separate I18N assemblies?
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:
> 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:
>> 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:
>>> 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
Re: [Mono-dev] Why do we need separate I18N assemblies?
OK, maybe you shouldn't be CCed, but actually this was the same thread.
Andreas did some tests and he mentioned string handling mistakes as another
reason. (He probably was or at least tried to be objective because not
everything is I18N's blame:)) And I asked him to explain what he means on
string handling mistakes. I hink this was an example rather than an actual
bug report.
(If you consider this message spam as well sorry for that but this message
is for you.)
Kornél
- Original Message -
From: "Atsushi Eno" <[EMAIL PROTECTED]>
To: "Andreas Nahr" <[EMAIL PROTECTED]>
Cc: "Kornél Pál" <[EMAIL PROTECTED]>;
Sent: Saturday, July 01, 2006 1:57 PM
Subject: Re: [Mono-dev] Why do we need separate I18N assemblies?
> 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:
>> 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:
>>> 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
V
Re: [Mono-dev] Component 1
Since I'm new to Mono, could somebody please explain how to do this? Also, how would I make the components available to mono to be used in building? > Actually most components I know of are managed code, so they should run on > mono. > If you are allowed you can simply take Reflector and look at the references > of your assembly and you will instantly see if the component is managed > only. > > mfg > Andreas > > - Original Message - > From: "Rafael Teixeira" <[EMAIL PROTECTED]> > To: "Rich Gilson" <[EMAIL PROTECTED]> > Cc: > Sent: Friday, June 30, 2006 9:00 PM > Subject: Re: [Mono-dev] Component 1 > > > The problem is, we don't know if the third-party controls/tools were > > developed with 100% managed and portable code, so you have to try them > > in Mono. > > > > Some years ago, most of the controls I tried were just wrappers to > > COM/ActiveX controls/components and surely those didn't run on Mono. > > Since I've being developing in Linux mainly and so without VS.NET and > > 3rd party components, so I can't say if that has changed. > > > > I know, from my friends on that front, that Delphi.NET users are tied > > to Windows, as the many useful frameworks Borland gave them aren't > > portable. > > > > :) > > > > On 6/30/06, Rich Gilson <[EMAIL PROTECTED]> wrote: > >> I'm working on porting an application at work to .NET and wanted to do > >> it in > >> Mono so that it could be run on both Linux and Windows, but I'm trying > >> to figure out if there is any what to use Third-Party tools in Mono? Or > >> are the tools that work on Visual Studio Windows-only? If they can be > >> used, how > >> would I go about using them and getting everything packaged together > >> when I > >> build it? > >> > >> Rich > >> > >> On 6/27/06, Rich Gilson <[EMAIL PROTECTED]> wrote: > >> > Is it possible to use any of the Component 1 objects in Mono? > >> > -- > >> > In a world without fences, who needs Gates? > >> > >> ___ > >> Mono-devel-list mailing list > >> Mono-devel-list@lists.ximian.com > >> http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > -- > > Rafael "Monoman" Teixeira > > --- > > "The reasonable man adapts himself to the world; the unreasonable one > > persists in trying to adapt the world to himself. Therefore all > > progress depends on the unreasonable man." George Bernard Shaw > > ___ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list -- In a world without fences, who needs Gates? pgpUIXwt7R2ed.pgp Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why do we need separate I18N assemblies?
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" <[EMAIL PROTECTED]>
> To: "Kornél Pál" <[EMAIL PROTECTED]>; "Atsushi Eno" <[EMAIL PROTECTED]>
> Cc:
> 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:
> > 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:
[Mono-dev] [PATCH] Add encoding deserialization proxies for System.Text
Hi, These proxy classes provide deserialization compatibility with internal encoding of MS.NET. Later we should modify our internal encoding classes to use these proxies instead their own classes, but that is only required for serialization compatibility. Please review and approve the patch. Kornél EncodingProxy.diff Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] 1.2 release?
Hello, Following up to Rafael's comments: The 1.1.xx releases are pretty much Mono 1.2, the only reason we have not renamed them to 1.2 is that Windows.Forms is not ready. > Also: my application is as I said 2.0, developed with Visual Basic. I > didn't find much difficoult to convert it to C# (with VBConversions' VB > to C# converter). But as you probably know, VB has the "my" namespace > wich wraps many classes.. will "my" be ported to linux or I have to use > classic C# calls to classes? If this is the case, I'll start migrating > "my" calls to standard framework calls (or build a personal wrapper for > those). No work exists currently to support "My", but will eventually be there. Work has started on this, but it will take at least half a year, maybe even more to have it completed. If you need something sooner, C# might be your best choice. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] genmdesc for MPC8xx
Hello, > I'm trying to build mono/ppc for an MPC8xx. Specifically, Freescale > MPC855. > > Where can I get the details I need to start building a new > mono/mini/cpu-mpc8xx.md file? I've been digging through the Freescale > reference docs, but I'm afraid they are a bit beyond me. Most likely the differences in this CPU are fairly minimal compared to the PowerPC port that we have. My suggestion would be to identify which instructions might not be present in the CPU and just modify the existing code generator. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Why do we need separate I18N assemblies?
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. 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. 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. The globalization code will likely be used shortly after, at least for any non-trivial program. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
