Question

JSF2.0 is an amazing web framework; While Rails/DJango/Play all basically use Templates with variable substitution (basicaly JSP), JSF2.0 is more biased to be a component based framework like Tapestry, GWT, and Wicket.

JSF has linear degrading performance with the complexity of your pages however. So after reading a fascinating article here:
http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead I had a few questions.

First, the author says that the majority of the time in JSF lifecycle is spent in buildView(). How would one profile this on a particular app, specifically, one running in Mojarra?

Second, would liberal use of f:ajax execute="" help with buildView() performance? Does the executeattribute cut down on the amount of work that buildView() has to do?

Finally, on a full page navigation, is there an equivalent of f:ajax that could say “only execute the following components while restoring the current view”? Is this nonsensical?

Thank you!

Answer 1

1. So it turns out it’s a tad difficult to profile this in Mojarra. However, MyFaces is pretty easy… Simple point your profiler at LifeCycleImpl.

2. On MyFaces, setting execute properly turns out to make huge performance gains. On my machine, buildView() boilerplate takes about 8ms. There is a linear cost added to that base for everyone component that’s processed in f:ajax execute=. I added 10,000 h:outputText in a ui:repeat surrounded by ui:fragment id="fragment". When I added fragment to the f:ajax execute= I went from 8ms response time to 45ms response time. The lesson here is to only set f:ajax execute= to only execute your input components and f:ajax render= only your h:message components.

3. The OmniFaces cache component essentially does this, but a little broader scope.

I still hope someone can chime in with more scientific answers 🙂