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

Kornél Pál kornelpal at gmail.com
Tue Jun 13 06:22:13 EDT 2006


Is this patch OK to commit?

Kornél

----- Original Message ----- 
From: "Kornél Pál" <kornelpal at gmail.com>
To: "Miguel de Icaza" <miguel at ximian.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Friday, June 09, 2006 2:24 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ByteEncoding.diff
Type: application/octet-stream
Size: 1796 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060613/51049454/attachment.obj 


More information about the Mono-devel-list mailing list