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

[Zac Bowling]

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>