[Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
Kornél Pál
kornelpal at gmail.com
Fri Jun 9 16:15:56 EDT 2006
UnicodeEncoding does this.;)
The thing you call native byte array is what Encoding.Default does.
Kornél
----- Original Message -----
From: "Zac Bowling" <zac at zacbowling.com>
To: "Kornél Pál" <kornelpal at gmail.com>
Cc: "Miguel de Icaza" <miguel at ximian.com>;
<mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 10:09 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
> Looks good from what I can tell.
>
> Sort of makes me think we should have a nice universal facility for
> casting a string to byte array just for us to use internally (not for
> the public to use because it can be an unsafe operation unless you know
> what you are doing and why microsoft never added toByteArray() and the
> ctor String(byte[]) functions in .NET as compared to Java). Maybe we
> could make what we did in the Unicode (utf16/ucs2) encoding more generic
> inside the string class? Something like the following functions:
>
> internal String(byte[] val, bool bigEndian);
> internal String(byte[] val); //assumes native
> internal byte[] ToByteArray(bool bigEndian);
> internal byte[] ToNativeByteArray();
> or
> internal static byte[] StringToByteArray(bool bigEndian);
> internal static byte[] StringToNativeByteArray();
> internal static String StringFromNativeByteArray(byte[] val);
> internal static String StringFromByteArray(byte[] val, bool bigEndian);
>
> Zac Bowling
> http://zacbowling.com/
>
> On Fri, 2006-06-09 at 14:24 +0200, Kornél Pál wrote:
>> OK, now I understan your problem.
>>
>> Please review this modified patch.
>>
>> Kornél
>>
>> ----- Original Message -----
>> From: "Miguel de Icaza" <miguel at ximian.com>
>> To: "Kornél Pál" <kornelpal at gmail.com>
>> Cc: <mono-devel-list at lists.ximian.com>
>> Sent: Friday, June 09, 2006 2:01 PM
>> Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
>>
>>
>> > Hello,
>> >
>> >> Invoking non-public methods using SRE is widely used by our class
>> >> library,
>> >> it is supported by the ECMA standards so I don't really understand
>> >> what
>> >> you
>> >> mean on "access to internal methods will at some point broken".
>> >
>> > As I said, this might be something that we will fix in the future, and
>> > although it works today, it does not mean it will work today, I do not
>> > want to add more dependencies that might prevent us from fixing it in
>> > the future.
>> >
>> > Besides, poking at string internals is not something am very excited
>> > about supporting nor encouraging. The last time we did something
>> > "unsafe" like this, it was reviewed over and over, and it turned out to
>> > be buggy, it took months to track the mysterious bug because the
>> > conditions were very hard to reproduce.
>> >
>> >> Note that even using "new string ((char) 0, length)" is faster than
>> >> the
>> >> current implementation.
>> >
>> > That part of the patch is fine with me.
>> >
>> > Miguel
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> --
> Zac Bowling <zac at zacbowling.com>
>
More information about the Mono-devel-list
mailing list