[Mono-dev] [PATCH] Speed up ByteEncoding.GetString()

[Kornél Pál]

I know that you know that's why I only referenced UnicodeEncoding instead of 
an explanation.:)

There is no need to add such methods because UnicodeEncoding does exactly 
this. Converting string <-> byte[] is simply not possible without memcpy as 
it has different underlaying structures.

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:43 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Yah I remember that about 4 or 5 months ago. :-P I was the one that
> pointed how slow it was and had that first patch to use memcopy from the
> string function :-)
>
> I'm just thinking that moving it to the string class might be better. I
> almost remember there were some other places where this would really
> useful in corelib (but might be thinking of the jscript string functions
> or something).
>
> Zac Bowling
> http://zacbowling.com/
>
> On Fri, 2006-06-09 at 22:15 +0200, Kornél Pál wrote:
>> 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>
>> >
>>
>> _______________________________________________
>> 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>
>