1 Reply Latest reply on Jun 15, 2009 4:26 AM by Jean Luc

    SeamELResolver performance issues

    Riccardo Serafin Newbie

      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.  

        • 1. Re: SeamELResolver performance issues
          Jean Luc Apprentice

          This is concerning - I noticed a certain slugginess of web pages with tables as well. I'll soon do some profiling and load tests as well - what you noticed is a concern, especially that after so many calls HotSpot would have compiled that code to native instructions. Thousands of calls to those methods to render a page - ouch.


          I see nothing much happened on the page about Seam's performance for over a year. Ouch, ouch :-(