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

[Zac Bowling]

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>