[jsr-314-open-mirror] [jsr-314-open] Proposal [868-DropCURRENT_COMPONENT CURRENT_COMPOSITE_COMPONENT]

[Blake Sullivan]

  On 8/17/10 2:19 AM, Imre Osswald wrote:
> Now it's me not to understand what you mean :)
> Did you mean to slow down implementing it, or the actual performance 
> of the implementation?
The actual performance of the implementation.  We've measured the 
performance of the current implementation and the overhead is 
non-negligible.  I agree that if the proposal is to reread the 
context-parameter on each call, that would be far too expensive.  
Faster, if grosser implementations could involve storing a final boolean 
on the UIComponent.

-- Blake Sullivan
>
> Implementing it the way Kito suggests, will probably be faster then 
> having to read a context-parameter, even if both solutions will have 
> neglectable impact overall.
>
> I guess adding two static PropertyDescriptors (with appropriate 
> read-methods) to the property descriptor map wouldn't add any 
> noticeable overhead. Returning null for the write-method will also 
> make them read-only as suggested (this probably should depend on a 
> context-parameter, but would postpone the evaluation of it until a 
> write call is made, which probably no one ever uses)
>
>
> Imre
>
> On 17.08.2010, at 05:06, Blake Sullivan wrote:
>
>> This would needlessly slow down the context attributes 
>> implementation, which is also hammered on.
>>
>> -- Blake Sullivan
>>
>> On 8/16/10 9:10 AM, Kito Mann wrote:
>>>
>>> On Mon, Aug 16, 2010 at 9:48 AM, Ed Burns <edward.burns at oracle.com 
>>> <mailto:edward.burns at oracle.com>> wrote:
>>>
>>>     >>>>> On Wed, 11 Aug 2010 11:46:21 -0400, Kito Mann
>>>     <kito.mann at virtua.com <mailto:kito.mann at virtua.com>> said:
>>>
>>>     KM> Couldn't you modify the map to return the constant values
>>>     for the
>>>     KM> proper keys? That way, they would be read-only values that don't
>>>     KM> need to be stored, the Map just needs to know the keys.
>>>
>>>     I'm sorry, I don't understand what you mean.  Can you please
>>>     restate it
>>>     differently?
>>>
>>>
>>> Basically, what I'm saying is that we could change the Map 
>>> implementation to simply delegate to 
>>> UIComponent.getCurrentComponent()  and 
>>> UIComponent.getCurrentCompositeComponent() in the get() method 
>>> whenever the key value is CURRENT_COMPONENT or 
>>> CURRENT_COMPOSITE_COMPONENT. This way we'd save space but would 
>>> maintain backwards compatibility without the switch.
>>>
>>>
>>>     Ed
>>>     --
>>>     | edward.burns at oracle.com <mailto:edward.burns at oracle.com> |
>>>     office: +1 407 458 0017
>>>     | homepage:               | http://ridingthecrest.com/
>>>     | 02 work days until JSF 2.1 Milestone 2
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100817/171359cb/attachment-0002.html