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 > >
