Hi Martin I think the code that do a lot of calls to FacesContext.getCurrentInstance() right now is on all listeners attached to system events.
One example is DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener. It is a listener attached to PostAddToViewEvent / PreRemoveFromViewEvent, but it requires to get the current FacesContext to do some operations. If we have one call here, that means this listener is being called once per each component in a tree. Doing some other different listeners I notice this is required over and over. It could be good to ask if it is possible modify the spec, so it could be possible to pass the current facesContext instance and prevent this lookup. regards, Leonardo Uribe 2010/5/24 Martin Marinschek <[email protected]> > Hi guys, > > well, yes - I fear so as well. > > I wonder if that development switch is used often in other places as > well - do we have that same performance problem somewhere else? > > best regards, > > Martin > > On Fri, May 21, 2010 at 6:17 PM, Jakob Korherr <[email protected]> > wrote: > > But this _could_ be a problem, or at least result in weird behavior, so I > > think it is the best solution just to remove the code from UIInput... > > > > Regards, > > Jakob > > > > 2010/5/21 Gerhard Petracek <[email protected]> > >> > >> yes - that's true! i also told leonardo about it. > >> in his e-mail he just skipped it... > >> regards, > >> gerhard > >> > >> http://www.irian.at > >> > >> Your JSF powerhouse - > >> JSF Consulting, Development and > >> Courses in English and German > >> > >> Professional Support for Apache MyFaces > >> > >> > >> > >> 2010/5/21 Martin Marinschek <[email protected]> > >>> > >>> Hi guys, > >>> > >>> if MyFaces is deployed with the web-app, the static var will reside in > >>> a class which is loaded by the context class-loader - so once per app. > >>> Problems might only arise if MyFaces is deployed only once for all > >>> web-apps - which will seldom be the case, I guess. > >>> > >>> best regards, > >>> > >>> Martin > >>> > >>> On 5/21/10, Jakob Korherr <[email protected]> wrote: > >>> > So the conclusion is to use a private static boolean on UIInput that > >>> > tells > >>> > us if we are in Development stage or not. > >>> > > >>> > Any objections to that? > >>> > > >>> > Regards, > >>> > Jakob > >>> > > >>> > 2010/5/20 Leonardo Uribe <[email protected]> > >>> > > >>> >> Hi > >>> >> > >>> >> 2010/5/19 Jan-Kees van Andel <[email protected]> > >>> >> > >>> >> Sounds plausible, we already do the same thing with the > >>> >> ExternalContexts > >>> >>> class. > >>> >>> > >>> >>> It's blazing fast, but the question is: Are we allowed to and do we > >>> >>> want > >>> >>> to cache the instance? > >>> >>> > >>> >>> > >>> >> In theory yes, because it does not change the behavior expected by > the > >>> >> spec. > >>> >> > >>> >> > >>> >>> If the spec doesn't dictate otherwise, I'm in favor of caching it. > >>> >>> > >>> >>> Another idea is to cache it in the ServletContext. It's not as fast > >>> >>> as a > >>> >>> static final field, but still pretty fast and can be inspected and > >>> >>> modified > >>> >>> through appserver tooling. > >>> >>> > >>> >>> > >>> >> The problem is from UIInput.setValue() or > UIInput.setSubmittedValue() > >>> >> we > >>> >> don't have access to ServletContext (the only way is through > >>> >> FacesContext.getCurrentInstance().getExternalContext(), and we want > to > >>> >> avoid > >>> >> the call to FacesContext.getCurrentInstance() ). > >>> >> > >>> >> Talking with Gerhard, the conclusion was a static var could do the > >>> >> job. Is > >>> >> just unrealistic assume someone has a production environment with > some > >>> >> applications with project stage "production" and others > "development" > >>> >> (note > >>> >> shared variables are "shared" by all applications hosted in a web > >>> >> server). > >>> >> In the worst case, the applications will continue working. > >>> >> > >>> >> regards, > >>> >> > >>> >> Leonardo > >>> >> > >>> >> > >>> >>> Regards, > >>> >>> Jan-Kees > >>> >>> > >>> >>> > >>> >>> 2010/5/19 Gerhard Petracek <[email protected]> > >>> >>> > >>> >>>> we don't have to cache the faces-context. > >>> >>>> we can use e.g. an interface with a static final field. > >>> >>>> > >>> >>>> usage (example): > >>> >>>> if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE)) > >>> >>>> { > >>> >>>> //... > >>> >>>> } > >>> >>>> > >>> >>>> -> there is just one evaluation. > >>> >>>> > >>> >>>> regards, > >>> >>>> gerhard > >>> >>>> > >>> >>>> http://www.irian.at > >>> >>>> > >>> >>>> Your JSF powerhouse - > >>> >>>> JSF Consulting, Development and > >>> >>>> Courses in English and German > >>> >>>> > >>> >>>> Professional Support for Apache MyFaces > >>> >>>> > >>> >>>> > >>> >>>> 2010/5/19 Leonardo Uribe <[email protected]> > >>> >>>> > >>> >>>> Hi > >>> >>>>> > >>> >>>>> The problem in this case is the only place we can store this > >>> >>>>> information > >>> >>>>> is the component instance itself. So, at least there is one > lookup > >>> >>>>> per > >>> >>>>> component. > >>> >>>>> > >>> >>>>> If we try to cache facesContext, unfortunately there is not safe > >>> >>>>> way to > >>> >>>>> clean this reference (portlet case), so there is a risk of use > old > >>> >>>>> instances > >>> >>>>> of this object in this case. > >>> >>>>> > >>> >>>>> regards, > >>> >>>>> > >>> >>>>> Leonardo Uribe > >>> >>>>> > >>> >>>>> 2010/5/19 Gerhard Petracek <[email protected]> > >>> >>>>> > >>> >>>>> hi, > >>> >>>>>> > >>> >>>>>> as long as we don't want to change the project stage > dynamically, > >>> >>>>>> we > >>> >>>>>> can just store e.g. a marker as static information. > >>> >>>>>> > >>> >>>>>> regards, > >>> >>>>>> gerhard > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> http://www.irian.at > >>> >>>>>> > >>> >>>>>> Your JSF powerhouse - > >>> >>>>>> JSF Consulting, Development and > >>> >>>>>> Courses in English and German > >>> >>>>>> > >>> >>>>>> Professional Support for Apache MyFaces > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> 2010/5/19 Jakob Korherr <[email protected]> > >>> >>>>>> > >>> >>>>>> Hi Martin, > >>> >>>>>>> > >>> >>>>>>> Indeed, we have to call FacesContext.getCurrentInstance() > >>> >>>>>>> everytime. > >>> >>>>>>> > >>> >>>>>>> So I guess it will be better to remove the code from UIInput! > >>> >>>>>>> > >>> >>>>>>> Regards, > >>> >>>>>>> Jakob > >>> >>>>>>> > >>> >>>>>>> 2010/5/19 Martin Marinschek <[email protected]> > >>> >>>>>>> > >>> >>>>>>> Hi Jakob, > >>> >>>>>>>> > >>> >>>>>>>> > The problem with this is that the code on UIInput checks the > >>> >>>>>>>> ProjectStage > >>> >>>>>>>> > everytime setSubmittedValue() or setValue() are called, > which > >>> >>>>>>>> > is > >>> >>>>>>>> very often > >>> >>>>>>>> > and could make MyFaces a bit slower, I guess. If we remove > >>> >>>>>>>> > this > >>> >>>>>>>> code on > >>> >>>>>>>> > UIInput, the debug output will stay mostly the same except > for > >>> >>>>>>>> > the > >>> >>>>>>>> call > >>> >>>>>>>> > stack, because this will be gone. > >>> >>>>>>>> > > >>> >>>>>>>> > The question now is if we should leave it the way it > currently > >>> >>>>>>>> > is > >>> >>>>>>>> (with the > >>> >>>>>>>> > code on UIInput and the possibility to display the call > stack) > >>> >>>>>>>> > or > >>> >>>>>>>> if we > >>> >>>>>>>> > should remove the code from UIInput (which means no slowdown > >>> >>>>>>>> > on > >>> >>>>>>>> > setSubmittedValue() and setValue() but loosing the call > >>> >>>>>>>> > stack). > >>> >>>>>>>> What do you > >>> >>>>>>>> > guys think? Any opinions/objections? > >>> >>>>>>>> > >>> >>>>>>>> for me it is a question how fast this getProjectStage() > >>> >>>>>>>> derivation > >>> >>>>>>>> is. > >>> >>>>>>>> If that means to call FacesContext.getCurrentInstance() all > the > >>> >>>>>>>> time, > >>> >>>>>>>> the impact is considerable (thread-local resolution). In this > >>> >>>>>>>> case > >>> >>>>>>>> it > >>> >>>>>>>> might be better to not have this information... > >>> >>>>>>>> > >>> >>>>>>>> Martin > >>> >>>>>>>> > >>> >>>>>>>> > Regards, > >>> >>>>>>>> > Jakob > >>> >>>>>>>> > > >>> >>>>>>>> > -- > >>> >>>>>>>> > Jakob Korherr > >>> >>>>>>>> > > >>> >>>>>>>> > blog: http://www.jakobk.com > >>> >>>>>>>> > twitter: http://twitter.com/jakobkorherr > >>> >>>>>>>> > work: http://www.irian.at > >>> >>>>>>>> > > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> > >>> >>>>>>>> -- > >>> >>>>>>>> > >>> >>>>>>>> http://www.irian.at > >>> >>>>>>>> > >>> >>>>>>>> Your JSF powerhouse - > >>> >>>>>>>> JSF Consulting, Development and > >>> >>>>>>>> Courses in English and German > >>> >>>>>>>> > >>> >>>>>>>> Professional Support for Apache MyFaces > >>> >>>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>>>> > >>> >>>>>>> -- > >>> >>>>>>> Jakob Korherr > >>> >>>>>>> > >>> >>>>>>> blog: http://www.jakobk.com > >>> >>>>>>> twitter: http://twitter.com/jakobkorherr > >>> >>>>>>> work: http://www.irian.at > >>> >>>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>> > >>> >>>> > >>> >>> > >>> >> > >>> > > >>> > > >>> > -- > >>> > Jakob Korherr > >>> > > >>> > blog: http://www.jakobk.com > >>> > twitter: http://twitter.com/jakobkorherr > >>> > work: http://www.irian.at > >>> > > >>> > >>> > >>> -- > >>> > >>> http://www.irian.at > >>> > >>> Your JSF powerhouse - > >>> JSF Consulting, Development and > >>> Courses in English and German > >>> > >>> Professional Support for Apache MyFaces > >> > > > > > > > > -- > > Jakob Korherr > > > > blog: http://www.jakobk.com > > twitter: http://twitter.com/jakobkorherr > > work: http://www.irian.at > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces >
