[Mono-dev] [PATCH] Speed up ByteEncoding.GetString()
zac at zacbowling.com
Fri Jun 9 16:09:21 EDT 2006
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();
internal static byte StringToByteArray(bool bigEndian);
internal static byte StringToNativeByteArray();
internal static String StringFromNativeByteArray(byte val);
internal static String StringFromByteArray(byte val, bool bigEndian);
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.
> ----- 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
Zac Bowling <zac at zacbowling.com>
More information about the Mono-devel-list