[Mono-devel-list] System.Web/System.Web.UI - patch (code synchronization between Mono and Mainsoft)

[Ilya Kharmatsky]

Ben Maurer wrote:

>On Sat, 2005-06-11 at 01:46 +0300, Ilya Kharmatsky wrote:
>  
>
>>    
>>
>>>What if you split up such arrays. IE:
>>>
>>>struct X {
>>>   int a; int b; int c;
>>>}
>>>
>>>X [] foo;
>>>
>>>Turns into:
>>>
>>>int foo_A [];
>>>int foo_B [];
>>>int foo_C [];
>>>
>>>  
>>>      
>>>
>>It is complicated task in perspective of our conveter - if it will use
>>you suggestion, it should
>>remember the context of each foo_X array (in order for example to call
>>proper functions etc.)
>>    
>>
>
>Ugh, yeah, that would be ugly.
>
>Easier way to do it: when you init the array, create all the objects:
>
>so you say:
>
>MyStructType [] x = new MyStructType [10]
>
>for (...)
>	x [i] = new MyStructType ();
>
>  
>
>>>The optimization of handling structs should take place in the .net ->
>>>java converter, not in our source code.
>>>      
>>>
>>And if usage of structs in specific place in our source code is
>>optional? I'm talking about specific
>>case. This is  not general proposal for optimization in every place,
>>where arrays of structs are used! 
>>    
>>
>
>Do you have benchmarks showing that this affects stuff by more than
>(say) 5% per request? This doesn't look like a perf critical area
>really.
>  
>
In "empty page" benchmark - under heavy stress - it took 3-5% of overall 
server side job.
I'm talking about "empty page", where no too much flows works.

>Even if code is in what is effectively #if 0, it has a cost. It makes
>our code harder to read, means that people must think about more code
>paths, and most importantly, increases the chances that a patch will
>cause a regression in your runtime.
>
>BTW, doesn't this show up with Hashtable, which also uses an array of
>structs?
>
>  
>

In Grasshopper we are using completely different implementation of 
Hashtable (BTW our
implementation doesn't use structs and works faster then mono's original 
hashtable and msft
hashtable).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050611/ee863af7/attachment.html