Leonardo Uribe píše v St 04. 08. 2010 v 14:26 -0500: > Hi > > 2010/8/4 Martin Koci <[email protected]> > Hi, > > today's results: > > myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in > RestoreViewExecutor.exectute > > mojarra: ~70 ms in RestoreViewPhase.execute > > > major gain comes from solution which I suggest in > MYFACES-2854: process > resource dependecies only for type, not for each instance of > that type. > Can this solution have disadvantages? > > > > Could you try with the patch proposed (MYFACES-2854-1.patch) ? Yes, I profile myfaces with that patch. That speeds it up to ~300 ms. But there are still thousands invocations of addComponentResource - see next comment
> > I think the solution proposed is not taking into consideration that in > a single request, > multiple views could be built (for example when there is a redirect on > PreRenderViewEvent). ah, yes that's true. So cache it per view then? Consider following scenario: a view with more then 800 UIInput components of same type (we have one such view, don't ask me why). That component declares dependency on 5 resources. This configuration creates 4000 invocation of addComponentResource but the result is insertion of 5 resources only! Resources adding per type reduces it to 5 invocations; 4000 vs. 5 is big difference. > > > Now the slowest part of restore view phase is creation of > composite > components during buildView() - > CompositeComponentResourceTagHandler.createComponent(FaceletContext) > leads to invovations of Tomcat's > WebappClassLoader.findResourceInternal(String, String). > Probably > composite components should be cached in production stage? > > > In theory, FaceletFactory cache them, isn't it? > I din't look into code, this result comes from yourkitprofiler, but probably caching is not working fine in this case, because count of invocation of findResourceInternal is same as count of composite components in tested view. I'll investigate it later. > regards, > > Leonardo Uribe > > > Regards, > > Martin Kočí > > Martin Koci píše v Po 02. 08. 2010 v 22:20 +0200: > > > Hi, > > > > quick results: yourkitprofiler marks as hot spot > > UiViewRoot.addComponentResource (3381 invocation count) - > that method > > itself creates 5 710 511 invocations of > AbstractIterator.next() > > > > Reason probably is that I have custom renderer for UInput > with > > @ResourceDependencies(...many @ResourceDependecy here). > > > > All invocations comes from > > > > org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply > recursively during restore view - VDL.buildView. > > > > Solution: @ResourceDependencies is static structure and > cannot change > > during lifecycle - call addComponentResource for particular > type of > > component (renderer, validator, ...) only once per one > lifecycle ? > > > > > > Thanks, > > > > Martin Kočí > > > > Jan-Kees van Andel píše v Po 02. 08. 2010 v 19:18 +0200: > > > Hey, > > > > > > > > > I'm very interested in the details behind those 750ms. Can > you post > > > the hotspots? Like: number of invocations, ms. self time > and ms. total > > > time. > > > > > > > > > Thanks. > > > > > > > > > Regards, > > > Jan-Kees > > > > > > > > > 2010/8/2 Martin Koci <[email protected]> > > > Hi, > > > > > > our profiling results show that myfaces are > significantly > > > slower in > > > restore view phase: > > > > > > com.sun.faces.... LifeCycle .. restoreView : 80 ms > > > > > > o.a.m.RestoreViewExecutor : 750ms! > > > > > > This result is perfectly reproducible in our case. > I profile > > > it on a > > > application real application - I cannot post test > case here. > > > > > > Configuration: myfaces or mojarra from trunk, > partial state > > > saving, a > > > view with more than 200 UIInput components. > > > > > > > > > Is it a known problem? I will provide more > detailed profiling > > > results > > > later. > > > > > > Regards, > > > > > > Martin Kočí > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
