1 2 3 4 Previous Next 53 Replies Latest reply on Dec 30, 2007 6:17 PM by mgrouch

    JBoss EL performance vs Sun EL

    mgrouch Expert

      Turns out that EL performance is the major reason (due to reflection calls) for
      slow page rendering with JSF (especially larger tables).

      Does JBoss EL impementation have any performance improvements
      compared to Sun EL?

      Thanks

        • 1. Re: JBoss EL performance vs Sun EL
          fhh Expert

          I very much doubt that. The reason why rendering large tables is slow in JSF is the building of the component tree.


          Regards

          Felix

          • 2. Re: JBoss EL performance vs Sun EL
            Mikael Andersson Master

            Hi

            I have also noticed performance issues when I use EL a lot with table rendering. Don't think it is specific to tables, just a lot of EL resolving going on. Not blaming EL, I am probably using it in ways it shouldn't be.

            In short when I added rendered property on each rich:column on a table, 6-8 seconds are spent in the render response lifecycle (when rendering about 100 rows). Compared milliseconds, when I remove the EL and just render all columns.

            There is a thread about it here:
            http://www.jboss.com/index.html?module=bb&op=viewtopic&t=118257

            - Mike

            • 3. Re: JBoss EL performance vs Sun EL
              Norman Richards Master

              I don't know that anyone has performance tested jboss-el.

              • 4. Re: JBoss EL performance vs Sun EL
                mgrouch Expert

                 


                I very much doubt that. The reason why rendering large tables is slow in JSF is the building of the component tree.


                No it is EL. I can see it in profiler.
                JSF doesn't have ability to define a variable so you have to
                recalculate EL expressions over and over (and that is using reflection!).
                JSF doesn't have if/else concept it only has 'rendered'
                so where you would normally had 'switch' statement evaluated once
                JSF has to evaluate 'rendered' again and again (with reflection!).

                I wonder if any thought on performance implications was given during JSF design...



                • 5. Re: JBoss EL performance vs Sun EL
                  mgrouch Expert

                  Here is some more interesting info on EL performance.
                  Looks like Eclipse also had problems and they managed to speed it up significantly.

                  http://dev.eclipse.org/mhonarc/lists/wtp-jsf-dev/msg00271.html

                  WTP 2.0 RC0 is targeted to release with a badly needed improvement to JSF EL validation performance.

                  Based on performance benchmarking you should see worst case performance roughly twice as fast and average case as much as 300 times faster when validating EL expressions involving #{bean.property} type expressions. I am also seeing a speed improvement of about 3 times when running my larger EL validation test suites.

                  Special thanks to Matthias Fuessel for providing us with a targeted caching mechanism to make this performance improvement possible.

                  To see all the details of the issue see:


                  https://bugs.eclipse.org/bugs/show_bug.cgi?id=163890


                  Can something like this be done to JBoss EL?
                  Thanks

                  • 6. Re: JBoss EL performance vs Sun EL
                    Pete Muir Master

                    I'm not sure that thread really relates to EL but to tooling for EL - it is discussing caching the results of scanning backing beans for valid EL - of course EL doesn't need to scan but resolve. Or am I missing some insight you've had?

                    • 7. Re: JBoss EL performance vs Sun EL
                      mgrouch Expert

                      Here is a piece of code to show what I'm trying to say.
                      In JSF EL same getters are called using reflections over and over again quite usually. So few reflection API calls could be spared and called once only.


                      import java.lang.reflect.Method;
                      
                      public class ReflectionTest {
                      
                       private String myProp = "VALUE";
                       Class[] argTypes = new Class[] { };
                       Object[] arg = new Object[0];
                       Method getterMethod;
                      
                       public Object getBeanProperty(Object bean, String propName) throws Exception {
                       Class clazz = bean.getClass();
                       String getterName = "get" + Character.toUpperCase(propName.charAt(0)) + propName.substring(1);
                       getterMethod = clazz.getDeclaredMethod(getterName, argTypes);
                       Object obj = getterMethod.invoke(bean, arg);
                       return obj;
                       }
                      
                       public Object getBeanPropertyViaCachedMethod(Object bean, String propName) throws Exception {
                       Object obj = getterMethod.invoke(bean, arg);
                       return obj;
                       }
                      
                       public String getMyProp() {
                       return myProp;
                       }
                      
                       public static void main(String... args) throws Exception {
                      
                       ReflectionTest testBean = new ReflectionTest();
                      
                       final int ITERATIONS = 1000000;
                      
                       long start = System.currentTimeMillis();
                       for (int i = 0; i < ITERATIONS; i++) {
                       String str = (String) testBean.getBeanProperty(testBean, "myProp");
                       //System.out.println(str);
                       }
                       long finish = System.currentTimeMillis();
                       System.out.println("Run1 time=" + (finish-start) + "ms");
                      
                       start = System.currentTimeMillis();
                       for (int i = 0; i < ITERATIONS; i++) {
                       String str = (String) testBean.getBeanPropertyViaCachedMethod(testBean, "myProp");
                       //System.out.println(str);
                       }
                       finish = System.currentTimeMillis();
                       System.out.println("Run2 time=" + (finish-start) + "ms");
                       }
                      }
                      


                      Outputs (on my PC)

                      Run1 time=2906ms
                      Run2 time=140ms


                      Now more or less realistic example:

                      Render table 1000 rows 10 columns each cell has a dropdown of 100 elements

                      That's a million reflection calls



                      • 8. Re: JBoss EL performance vs Sun EL
                        mgrouch Expert

                        Now here is an illustration how ridiculously inefficient JSF design is.
                        It forces developer to write the most inefficient code

                        Example:

                        based on type value stored in columnBean.type you need to render
                        several different HTML controls

                        So you would have to repeat

                        <s:fragment rendered="#{columnBean.type == 'type1'">
                         fragment1
                        </s:fragment>
                        
                        and so on.


                        In regular programming language there would be a 'switch' statement
                        and since conditions are mutually exclusive after one condition is met
                        there is no need to evaluate others.

                        1) In JSF for N mutually exclusive 'rendered' conditions they will
                        ALWAYS be evaluated N times!!!

                        2) Even worse there is no syntax to assign columnBean.type to a variable
                        so it will be EVALUATED EACH TIME!!!

                        3) Even worse it will be evaluated using REFLECTION!!!

                        4) JSF will give you temptation to write condition as STRING comparison
                        (Though this is avoidable, but most people write it exactly that way cause
                        declaring a constant is not supported)

                        Please, correct me if I'm wrong about something. (Might be things are not that bad)





                        • 9. Re: JBoss EL performance vs Sun EL
                          Hayden Livingston Newbie

                          So, you're saying a Data Grid listing with 100 rows is going to take like many seconds to render?

                          I haven't joined the JBoss Seam bandwagon yet. I was going to, but are these performance issues going to persist? Change in JSF 2.0? etc? Or is it better to try Wicket?

                          • 10. Re: JBoss EL performance vs Sun EL
                            Pete Muir Master

                            No, it shouldn't take many seconds. JSF does have an overhead, however I'm not an expert on this and so can't provide a definitive answer. Some people have done extensive performance work on JSF/Facelets (Adam Winer springs to mind) - you should be able to find it by googling.

                            N.B. Eelco has basic Seam integration in Wicket (not sure what version of Wicket, or perhaps CVS)

                            • 11. Re: JBoss EL performance vs Sun EL
                              mgrouch Expert

                               

                              So, you're saying a Data Grid listing with 100 rows is going to take like many seconds to render?


                              Yes depending on how many controls you are putting inside table,
                              and how man times you invoke EL I've seen ~3-5 sec rendering phase times
                              even with 100 rows (on 2GHz PC)


                              Most of the invocations from EL are getters so might
                              you could have something like invokeGetter() method which will
                              skip much of logic which is designed to support generic invocations in

                              ReflectionUtil.java

                              http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss-el/trunk/src/org/jboss/el/util/ReflectionUtil.java

                              Was there any stress testing and profiling done on JBoss EL previously?

                              Thanks



                              • 12. Re: JBoss EL performance vs Sun EL
                                Chris Lowe Apprentice

                                Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?

                                In addition to all the EL parsing, reflection, etc. the EL calls will probably be subject to several layers of interception. Do these show up in your timings?

                                I know you've run a profiler on the session and currently all fingers point to EL, but another thing to consider is that there are certain cases in IE where the browser itself is incredibly slow at rendering tabular data. I had a JSF app that rendered incredibly slowly. After profiling, I saw that the response was generated in a fraction of the time that I was witnessing. Even after saving the generated HTML to a file and opening up in IE it generated slowly. Opening the same file in Firefox was very quick. Like I said, probably not directly relevant here, just something to look out for.

                                • 13. Re: JBoss EL performance vs Sun EL
                                  mgrouch Expert

                                   

                                  Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?


                                  I posted some code before https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=625

                                  In addition to all the EL parsing, reflection, etc. the EL calls will probably be subject to several layers of interception. Do these show up in your timings?


                                  I haven't really investigated impact of interseption. I my past experience
                                  of rendering tables without Seam it was slow too.

                                  I know you've run a profiler on the session and currently all fingers point to EL, but another thing to consider is that there are certain cases in IE where the browser itself is incredibly slow at rendering tabular data.


                                  I've seen it too, but I'm not talking here about client side.
                                  I'm clocking renderding phase on server side. (JSF Phase listener
                                  displays timing of all JSF phases on server side).



                                  • 14. Re: JBoss EL performance vs Sun EL
                                    mgrouch Expert


                                    Are you able to post some actual code that demonstrates these performance issues: (beans, facelets etc)?


                                    One easy way to demo it: Create a large table and render dropdowns
                                    with s:selectItems in each cell.

                                    It can be used for stress testing EL, rendering, form submission, validation, etc.

                                    Thanks


                                    1 2 3 4 Previous Next