myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kito Mann <kito.m...@virtua.com>
Subject Re: [core] performance: avoid wrapped EL Expressions
Date Sun, 05 Jun 2011 16:16:21 GMT
Ah, okay. Thanks for the explanation, Leonardo.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

* Listen to the latest headlines in the JSF and Java EE newscast:
http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
* See you at JAX and JSF Summit 2011 June 20-23rd in San Jose:
http://jaxconf.com/


On Fri, Jun 3, 2011 at 6:45 PM, Leonardo Uribe <lu4242@gmail.com> wrote:

> Hi Kito
>
> No, this will reduce the number of value/method expressions created
> each request, but the calls to getters during request will be the
> same.
>
> In my understanding, some additional getter calls are triggered by
> effect of ve.getType(). The only way to prevent that is define the
> type beforehand (for example, tomahawk has valueType property in some
> extended standard components).
>
> Anyway, the optimization proposed is significant, because create such
> expressions takes valuable cpu and memory resources.
>
> Leonardo
>
> 2011/6/3 Kito Mann <kito.mann@virtua.com>:
> > Leonardo, would this reduce the number of calls to getters during request
> > processing?
> > ---
> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter:
> > jsfcentral
> > +1 203-404-4848 x3
> >
> > * Listen to the latest headlines in the JSF and Java EE
> > newscast:
> http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> > * See you at JAX and JSF Summit 2011 June 20-23rd in San
> > Jose: http://jaxconf.com/
> >
> >
> > On Thu, Jun 2, 2011 at 10:10 PM, Leonardo Uribe <lu4242@gmail.com>
> wrote:
> >>
> >> Hi
> >>
> >> I have attached another patch to MYFACES-3160. This one has the
> >> ability to detect if the expression uses some variable resolved by
> >> facelets VariableMapper wrappers and if so, indicate the expression
> >> cannot be cached.
> >>
> >> This solution will work better, because it only creates Value/Method
> >> expressions when it is necessary. This is a great optimization,
> >> because in practice most expressions are bound to managed beans, so in
> >> practice it will make pages render faster (because EL parsing is only
> >> done once and a lot of objects will not be created) and the memory
> >> usage will be lower (less instances means gc works less).
> >>
> >> The only part this does not have any effect is when there is a
> >> ValueExpression directly on the markup. In this case, I think since
> >> org.apache.myfaces.view.facelets.compiler.UIInstructionHandler is
> >> final (that means it is inmutable), put a volatile variable for cache
> >> such cases will make it a mutable class, so it cannot take advantage
> >> of some compiler optimizations. Maybe we can create two classes, one
> >> to handle markup without EL and other with EL. Anyway, the most
> >> critical point is expressions on attributes (changes on facelets
> >> compiler has to be done very carefully).
> >>
> >> JK> I would really like to see some prototyping work for JSF 2.2 in this
> >> JK> area directly in a MyFaces core branch!
> >>
> >> The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. After
> >> the latest patch I think we don't really need some work on a EL
> >> implementation (see explanations below).
> >>
> >> MK>>
> >> MK>> we need to avoid unnecessary ValueExpression instances.
> >>
> >> Yes, sure!. I know this optimization will be very useful, and it will
> >> do better use of available resource (memory and cpu).
> >>
> >> MK>>
> >> MK>> Here is one idea: because we cannot wait for JCP (or I don't want
> >> to),
> >> MK>> prototype some improvements in sandbox, for example:
> >> MK>>
> >> MK>> 1)  we can create MyFacesExpressionFactory with methods
> >> MK>> createTagValueExpression, createLocationValueExpression,
> >> MK>> createResourceLocationValueExpression ....
> >> MK>>
> >>
> >> The problem here is the hacks required to make #{cc} and resource
> >> "this" are too myfaces specific, and are too coupled to myfaces impl.
> >>
> >> MK>> 2) In myfaces-core-impl then create default implementation with
> same
> >> MK>> code as TagAttributeImpl.getValueExpression(FaceletContext, Class)
> >> has
> >> MK>> currently.
> >> MK>>
> >>
> >> It could be good to have a factory pattern applied to that part.
> >>
> >> MK>> 3) create new module myfaces-integration with additional
> >> implementations
> >> MK>> of MyFacesExpressionFactory. For example
> >> JUELOWBMyFacesExpressionFactory
> >> MK>> - create* methods of such implementation will create not wrapped
> >> MK>> expression but  one instance of JUELCODIValueExpression.
> >> MK>> JUELCODIValueExpression will use inheritance from JUEL internal API
> >> (and
> >> MK>> some code from OWB).
> >> MK>>
> >> MK>> Of course it will need cooperation with JUEL/OWB developers (for
> >> example
> >> MK>> because de.odysseus.el.TreeValueExpression from JUEL is final
> class).
> >> MK>> Solution with inheritance is proposal only, I didn't try it yet.
> User
> >> MK>> must be sure that no other library wants to wrap ValueExpression.
> >> MK>>
> >>
> >> In my mind this only works as a "last resource". VariableMapper usage
> >> is only a concern inside facelets, because its usage is bound to the
> >> context the expression is created.
> >>
> >> Anyway, I would like to know first if it is really necessary to create
> >> such factories. We need concrete use cases that support that. For now,
> >> I'll be happy with the solution proposed. It still requires a deep
> >> review (because the code affected is very critical) and some junit
> >> tests, so it will take some time before finish it.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >
> >
>

Mime
View raw message