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

[Kornél Pál]

Hi,

> Anyways it matches my understanding. Now we are ready to revert your
> changes depending on the future direction without extra discussion
> which might happen, as well as the possibility to add extra reflection
> dependency. I don't like such extra dependency though, since it makes
> code impossible to reuse or to try on other platforms than existing
> mono itself.

I have the same opinion regarding these things so I'm happy.:) And anyway I 
like to discuss things because I believe that discussing different opinions 
has good results. Note that I didn't committed any reflection related thinks 
so there is nothing to revert.

I don't like late binding either (unless really necessary) but not because 
of CAS rather than because it causes no compilation error so makes the code 
more difficult to maintain and late binging is less efficient than 
compile-time linking.

When I tried "new string ((char) 0, length)" I noticed that altough it's 
slower than InternalAllocateStr, when InternalAllocateStr is called using a 
late binding the performance gain is little so it's better to avoid 
reflection in this case.

Note that I posted this patch but it was out of interest:
http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016253.html

But there allways were different views: for example I was asked to impement 
functionality in corlib and use it from mcs using reflection:
http://lists.ximian.com/pipermail/mono-devel-list/2006-March/017409.html

(BTW I should repost the modified version of this patch at some time in the 
future.:)

All solutions has advantages and drawbacks as well. I was debating about 
reflection becuase there should be some solution to the problem of internal 
interopability of the class library and/or compilers instead following 
different ways.

Microsoft uses public methods then documents that "This type/member supports 
the .NET Framework infrastructure and is not intended to be used directly 
from your code." - I think we should not follow this strategy.

Other solution is to use reflection on non-public types/members that has the 
disadvantages we have discussed.

Or use InternalsVisibleToAttribute that is not available in profile 1.x. - 
By hacking the runtime and mcs to allow this attribute type be declared in 
the assembly privately and serve the same purpose this problem could be 
solved however and this solution provides the best performance.

You mentioned code reusing on other platforms. Regardless of the methods 
used when using non-standard or non-public members or types this is a 
problem. But for example the interaction between System.Windows.Forms and 
System.Drawing or between mono-service and System.ServiceProcess is required 
in order to be possible to implement their functionality so some solution 
should be preferred and used.

Kornél

----- Original Message ----- 
From: "Atsushi Eno" <atsushi at ximian.com>
To: "Kornél Pál" <kornelpal at gmail.com>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, June 14, 2006 7:15 PM
Subject: Re: [Mono-dev] [PATCH] Speed up ByteEncoding.GetString()


> Kornél Pál wrote:
>>> I am confused: which is your true opinion?
>>>
>>> 1)
>>>
>>> > OK, now I understan your problem.
>>
>> This is not an opinion. This is only a feedback that I have understood 
>> Miguel's problem he was speaking of. But I don't means that I have the 
>> same opinion.
>>
>>> 2)
>>>
>>>> It may be improper to assume that there is an internal method called 
>>>> InternalAllocateStr even more improper to assume that strings can be 
>>>> modified but I don't think that using reflection to access non-public 
>>>> members is improper.
>>
>> This is my opinion. And another important opinion is that if we assume 
>> that our class library assemblies have permission to use unsafe code and 
>> P/Invoke that are higher privileges we can assume that they have 
>> reflection permissions as well. If they hasn't got these permissions 
>> exceptions will be raised but this is true for unsafe code and P/Invoke 
>> as well. So if our opinion is that we should not depend on permissions we 
>> should not use either unsafe code or P/Invoke. And I think this is 
>> somethig we don't want. But if our opinion is that it's OK to require 
>> full trust or highly privileged permissions at least we can use 
>> reflection as well.
>
> Then it is very hard to understand why you posted a revised patch
> that just removed reflection stuff. No one would think that you
> disagree with Miguel when he or she read that reply.
>
> Anyways it matches my understanding. Now we are ready to revert your
> changes depending on the future direction without extra discussion
> which might happen, as well as the possibility to add extra reflection
> dependency. I don't like such extra dependency though, since it makes
> code impossible to reuse or to try on other platforms than existing
> mono itself.
>
> Atsushi Eno