myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Koci <martin.k...@aura.cz>
Subject Re: Trinidad and JSF 2.0
Date Thu, 03 Dec 2009 22:17:58 GMT
Hi,

regarding component.getAttributes() vs. bean.getProperty() performance:

do you have info under which circumstances is that difference
noticeable? I do some profiling on two apps: the first one is
trinidad12/jsf12 based and the second is JSF2 based. In both cases I
have same view but JSF2 based application uses UIComponent and newly
developed renderers instead trinidad. For example: CoreInputText ->
NewInputText and SimpleInputTextRenderer -> NewSimpleInputTextRenderer.
Algorithm in new renderers is the same as in trinidad but uses
getAttributes() directly.

I didn't notice a performance regression but maybe I look at wrong
places. Obviously it must cost something especially during render
response. Test is done for very complex view, loading is simulated as
100 concurrently working users - but YourKitProfiler shows very similar
results for render response phase. Memory profiling I didn't do yet.


Thanks,

Martin Kočí

Gabrielle Crawford píše v Čt 03. 12. 2009 v 09:29 -0800:
> Hi,
> 
> Our implementation of facesBean in 1.2 already supported 
> partialStateSaving, and for JSF 2 it's now a partialStateHolder
> https://issues.apache.org/jira/browse/TRINIDAD-1630
> 
> One reason is FacesBean uses propertyKeys, which allow additional 
> information like capabilities.
> 
> Beyond that Andy Schwartz had actually taken a look at this previously. 
> Here's what he found.
> 
> In theory the ideal solution should be to remove FacesBean in favor of 
> the new standard APIs. However, in practice, there are two issues:
> 
>    1. We need to maintain backwards compatibility.
>    2. Trinidad's FacesBean solution is more efficient than the standard 
> solution.
> 
> Note that the compatibility issues (#1) mainly impact component/renderer 
> authors (not application developers), yet is still an important issue 
> for us.
> 
> Regarding efficiency (#2)... FacesBean has two benefits over the 
> standard solution. First, FacesBean supports indexed property keys, 
> allowing for very efficient property lookups. Second, the Trinidad 
> approach avoids overhead involved in the JSF's attribute-property 
> transparency mechanism. When using the RI's implementation of 
> UIComponent.getAttributes().get("foo"), the following steps are performed:
> 
>     * First, look up the attribute in the attribute map.
>     * If not found, use reflection to call the property getter (eg. 
> getFoo()) on the component instance.
>     * The getter then performs yet another lookup on the StateHelper.
> 
> This approach allows property look ups to be more easily customized via 
> subclassing (ie. by overriding accessor methods). Trinidad sacrifices 
> this flexibility for performance. Attribute lookups are routed directly 
> to the FacesBean without invoking component accessor methods.
> 
> Thanks,
> 
> Gabrielle
> 
> 
> Matthias Wessendorf wrote:
> > quick comment...
> >
> > one reason to keep that structure is that the components (trinidad) offer
> > more APIs and behavior.
> >
> > Also, not sure if we really want to go with JSF 2.0's partial state saving.
> > Looks like FacesBean has still some advantages.
> >
> > Gabrielle, can you provide some data here ?
> >
> > -Matthias
> >
> > On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
> > <jankeesvanandel@gmail.com> wrote:
> >   
> >> Hey,
> >>
> >> I'm just asking this out of curiosity, so no offense intended. ;-)
> >>
> >> I see a lot of JSF 2.0 related activity in Trinidad and I was
> >> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
> >> Are there (legacy) reasons to keep the UIX classes and not replace
> >> them (maybe partially) with their JSF 2.0 equivalents?
> >>
> >> I can imagine that interoperability with other libraries increases
> >> when Trinidad builds on (or extends) the JSF 2.0 API.
> >>
> >> Regards,
> >> Jan-Kees
> >>
> >>     
> >
> >
> >
> >   
> 



Mime
View raw message