Re: Myfaces vs. mojarra restore view performance
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
Re: Myfaces vs. mojarra restore view performance
Hi
Yes, sure!. Give me some time, right now I'm doing some stuff related to
@ListenerFor annotation, so as soon as I'm done I'll take a look.
regards,
Leonardo
2010/9/30 Martin Koci martin.kocicak.k...@gmail.com
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
Re: Myfaces vs. mojarra restore view performance
MArtin,
your account is now setup - you even could apply them yourself,
after Leo did a successful review
-;M
On Thu, Sep 30, 2010 at 1:14 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Myfaces vs. mojarra restore view performance
Hi
Both optimizations are ok. +1
If you want I can commit it but I suggest you commit them.
regards,
Leonardo
2010/9/30 Matthias Wessendorf mat...@apache.org
MArtin,
your account is now setup - you even could apply them yourself,
after Leo did a successful review
-;M
On Thu, Sep 30, 2010 at 1:14 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Myfaces vs. mojarra restore view performance
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
Re: Myfaces vs. mojarra restore view performance
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to 30-40 ms.
It is necessary to apply @ListenerFor annotations on every component that
has registered
it in the view. The reason why we can cache @ResourceDependency is this
annotation
cause a component resource to be added, and that one will be always the
same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
Re: Myfaces vs. mojarra restore view performance
Hi, success! myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view phase. It was *750 ms* before. Thanks, Martin Kočí Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500: Hi I implemented a proposal for this one on MYFACES-2854-2.patch using the suggestion proposed (do not apply ResourceDependency if it was already processed). I hope that patch solve the problem. regards, Leonardo
Re: Myfaces vs. mojarra restore view performance
Hi Ok, good to know that. I closed MYFACES-2854. Maybe on MYFACES-2862 we can use FacesContext.isProjectStage(ProjectStage). regards, Leonardo 2010/8/5 Martin Koci martin.k...@aura.cz Hi, success! myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view phase. It was *750 ms* before. Thanks, Martin Kočí Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500: Hi I implemented a proposal for this one on MYFACES-2854-2.patch using the suggestion proposed (do not apply ResourceDependency if it was already processed). I hope that patch solve the problem. regards, Leonardo
Re: Myfaces vs. mojarra restore view performance
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? 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? 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 martin.k...@aura.cz 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čí
Re: Myfaces vs. mojarra restore view performance
Hi 2010/8/4 Martin Koci martin.k...@aura.cz 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.patchhttps://issues.apache.org/jira/secure/attachment/12451185/MYFACES-2854-1.patch) ? 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). 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? 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 martin.k...@aura.cz 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čí
Re: Myfaces vs. mojarra restore view performance
Leonardo Uribe píše v St 04. 08. 2010 v 14:26 -0500: Hi 2010/8/4 Martin Koci martin.k...@aura.cz 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 martin.k...@aura.cz 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čí
Re: Myfaces vs. mojarra restore view performance
Hi I implemented a proposal for this one on MYFACES-2854-2.patchhttps://issues.apache.org/jira/secure/attachment/12451299/MYFACES-2854-2.patchusing the suggestion proposed (do not apply ResourceDependency if it was already processed). I hope that patch solve the problem. regards, Leonardo
Re: Myfaces vs. mojarra restore view performance
https://issues.apache.org/jira/browse/MYFACES-2854 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 martin.k...@aura.cz 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čí
Myfaces vs. mojarra restore view performance
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čí
Re: Myfaces vs. mojarra restore view performance
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 martin.k...@aura.cz 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čí
Re: Myfaces vs. mojarra restore view performance
Martin, We've been seeing some similar bottlenecks in our testing on Websphere. We've think we have it isolated down to where the largest portion of the impacts are coming from checkResourceExists() in DefaultViewHandlerSupport and DefaultRestoreViewSupport. The problem, at least in our testing, is because they both call ExternalContext.getResource(), which subsequently calls into ServletContext.getResource(). This method has to make an expensive file system check to see if the file exists prior to returning the URL. The penalty is even worse if the resource is in a jar since you have to crack open the jar. I'm currently working on a simple caching solution that in initial testing has resulted in a very large reduction in average response time but its still a work in progress. I'm waiting on further profiling from our performance team. I'll have to check with legal to see what I'm allowed to disclose as far as numbers due to this testing being on pre-release WAS builds. Either way, once I get some more testing results from our performance guys and do some regression testing I can upload a patch for you to try out with your tests to see what improvements you get with the caching. I should have something later this week. Thanks, Mike On 8/2/2010 12:44 PM, Martin Koci wrote: 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čí
Re: Myfaces vs. mojarra restore view performance
UIInput is slow, we already have bugs for that -Matthias On Mon, Aug 2, 2010 at 7:18 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: 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 martin.k...@aura.cz 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čí -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Myfaces vs. mojarra restore view performance
One thing I noticed while testing my Ajax stuff is that Mojarra has some ViewScope optimizations, in MyFaces a deserialisation method I set on a ViewScoped bean always got called. In Mojarra it never was in the ppr case. I can run my tests again to get the exact behavior. Also have a serious look a user recently filed on following issue: http://issues.apache.org/jira/browse/MYFACES-2823 This definitely could be the cause of a huge performance bottleneck. Werner Am 02.08.10 19:18, schrieb Jan-Kees van Andel: 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 martin.k...@aura.cz mailto:martin.k...@aura.cz 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čí
Re: Myfaces vs. mojarra restore view performance
Hi There is an issue open related to checkResourceExists() call: MYFACES-2628 Facelets ResourceSolver cant work : Make this call crash facelets ResourceSolver, it was suggested this issue. The previous evidence suggest the following line: ViewDeclarationLanguage vdl = viewHandler.getViewDeclarationLanguage(facesContext, restoreViewSupport.deriveViewId(facesContext, viewId)); Is the problem. The documentation says this about getViewDeclarationLanguage: Return the ViewDeclarationLanguage instance used for this ViewHandler instance. The default implementation must use ViewDeclarationLanguageFactory.getViewDeclarationLanguage(java.lang.String) to obtain the appropriate ViewDeclarationLanguage implementation for the argument viewId. Any exceptions thrown as a result of invoking that method must not be swallowed. The default implementation of this method returns null. In theory, getViewDeclarationLanguage(facesContext, viewId) receive the viewId after derive it, but the evidence suggest here we could receive the rawViewId, so getViewDeclarationLanguage() should do the required steps to derive the view id without call checkResourceExists(). I'll do some tests to see what happen. regards, Leonardo Uribe 2010/8/2 Matthias Wessendorf mat...@apache.org UIInput is slow, we already have bugs for that -Matthias On Mon, Aug 2, 2010 at 7:18 PM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: 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 martin.k...@aura.cz 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čí -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Myfaces vs. mojarra restore view performance
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 martin.k...@aura.cz 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čí
