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 <lu4...@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.m...@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 <lu4...@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 > > > > >
