Hello,
in the last few weeks I've been profiling my app, trying to follow the various suggestion I found on the forum.
After applying all suggestions (including the ones in Dan Allen article at jsf central), I'm still not happy with the general performance.
Using the jip profiler, enabling the profiling of my app, seam, richfaces and ajax4jsf classes, i found out that during a simple page refresh 87% of the time is spent within seam methods. In particular, 33% is accountable to the lookupInStatefulContexts method of the Contexts class. After digging a little more, and debugging a bit, it looks to me that the real responsible is the SeamELResolver.
What I have noticed is the following: let's suppose that i have an a4j:repeat with an iteration variable called menu
. Every time this variable is resolved in an EL expression, the SeamELResolver is called first. The resolver starts then to look for a component called menu
in the root context, and then in each of the imported name spaces. For each of these namespaces, the getComponent method is called, which in the end calls the lookupInStatefulContexts. Now, menu
is not a seam component, so it is never found and for each call all contexts are scanned.
In the end, for a not so complex page, I get more than 4000 calls to lookupInStatefulContexts and 17000 calls to Component.forName() (which is the second most time consuming method).
So, even if I get why the resolver works the way it does, I'm a little perplexed about the overall performance, 'cos every variable that is not a seam component still requires a full, costly, seam contexts search.
Is there anyway to reduce this performance problem? Is it possible that the order of the SeamELResolver in the resolver chains is the root of the problem?
Thanks,
Riccardo.
