1 2 3 4 Previous Next 53 Replies Latest reply on Dec 30, 2007 6:17 PM by mgrouch Go to original post
      • 15. Re: JBoss EL performance vs Sun EL
        christian.bauer

        Why is everybody guessing what and where a performance problem might be? It would be very easy indeed to just create a snapshot with a profiler and posting it here.

        • 16. Re: JBoss EL performance vs Sun EL

          To avoid guess here is a test case

          import java.io.Serializable;
          
          import org.jboss.seam.annotations.Name;
          
          @Name("testBean")
          public class TestBean implements Serializable {
          
           public final static int ROWS = 1000;
           public final static int COLS = 10;
           public final static int ITEMS = 100;
          
           private String data[][][] = new String[ROWS][COLS][ITEMS];
          
           public TestBean() {
           for (int i=0; i<ROWS; i++) {
           for (int j=0; j<COLS; j++) {
           for (int k=0; k<ITEMS; k++) {
           data[j][k] = "[" + i + "," + j + "," + k + "]";
           }
           }
           }
           }
          
           public String[][][] getData() {
           return data;
           }
          
           public void setData(String[][][] data) {
           this.data = data;
           }
           }
          


          JSF

           <table>
           <tbody>
           <tr>
           <ui:repeat value="#{testBean.data}" var="row" varStatus="index">
           <td>
           <ui:repeat value="#{row}" var="col">
           <select>
           <ui:repeat value="#{col}" var="item">
           <option value="#{item}">#{item}</option>
           </ui:repeat>
           </select>
           </ui:repeat>
           </td>
           </ui:repeat>
           </tr>
           </tbody>
           </table>
          



          JSP

          <%@page import="com.mydomain.biz.bean.TestBean"%>
          <html>
          <head>
          </head>
          <body>
          <table>
          <%
           TestBean bean = new TestBean();
           for (int i=0; i<TestBean.ROWS; i++) {
          %>
           <tr>
          <%
           for (int j=0; j<TestBean.COLS; j++) {
          %>
           <td>
           <select>
          <%
           for (int k=0; k<TestBean.ITEMS; k++) {
           String data = bean.getData()[j][k];
           %>
           <option value="<%=i%>_<%=j%>_<%=k%>"><%=data%></option>
           <%
           }
           %>
           </select>
           </td>
           <%
           }
           %>
           </tr>
           <%
           }
           %>
           </table>
           </body>
           </html>
          


          I don't have profiler handy, but I swear it was EL functions which topped the list in it.



          • 17. Re: JBoss EL performance vs Sun EL
            halivingston

            Are we addressing these issues in JSF 2.0? If the culprit is JSF i.e.

            Disappointing if I have to use Wicket, because Seam is just looking so good for my project. But the demos on my 2.6Ghz machine run slow, as compared to say a PHP equivalent of those applications (seam-booking)

            So, will Seam outperform PHP, and the likes under stress? Because single execution the PHP pages outperform Seam by a stretch?

            • 18. Re: JBoss EL performance vs Sun EL
              gavin.king

               

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


              Well, sure.

              But note that a switch statement is also involves n potential evaluations. I'm not sure what the difference is? I guess you can emulate a switch using nested f:subviews.

              If this particular issue is truly a problem, it is possible to decide which fragment to render in your Java code by using rendered="false" on all N fragments and calling UIComponent.setRendered(true) explicitly before the render phase.

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


              In components.xml, type:

              <factory name="columnBeanType" scope="request" value="#{columnBean.type}"/>


              Perhaps that "trick" addresses your concerns?

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


              It has been a really long time since a reflective method invocation was significantly slower than a normal method call. This seems to be a red herring.

              4) JSF will give you temptation to write condition as STRING comparison


              I don't know what you mean.



              • 19. Re: JBoss EL performance vs Sun EL
                gavin.king

                 

                "halivingston" wrote:
                So, will Seam outperform PHP, and the likes under stress? Because single execution the PHP pages outperform Seam by a stretch?


                Seam is definitely not going to outperform something like PHP for simple page rendering. The level of abstraction is so much higher!

                However, there are two reasons why Seam can beat PHP in more advanced cases:

                * Seam can do much more efficient caching of state, avoiding hits to the database
                * The Java EE server is just, by nature, more scalable



                • 20. Re: JBoss EL performance vs Sun EL

                  Gavin,

                  My critique was addressed to JSF not Seam.
                  I think Web Remoting in Seam might look more promising than JSF.
                  JSF IS slow. Java component development in it requires lots of labor.

                  What do you think about web remoting with something like

                  http://extjs.com/

                  which open source LGPL licensed.
                  Demo is here http://extjs.com/.

                  What would think is more appealing?

                  Thanks

                  • 21. Re: JBoss EL performance vs Sun EL

                    Here are some results of performance testing:

                    With the code I've posted in this thread (I've modified it to put
                    100 rows, 100 columns, 100 items in dropdowns).

                    Rendering table using JSP

                    $ time curl http://localhost:8080/TestJSP/testTable.jsp > foo.jsp
                     % Total % Received % Xferd Average Speed Time Curr.
                     Dload Upload Total Current Left Speed
                    100 49.4M 0 49.4M 0 0 6025k 0 --:--:-- 0:00:08 --:--:-- 3884k
                    
                    real 0m9.566s
                    user 0m0.124s
                    sys 0m0.765s


                    Rendering table using Seam/JSF

                    $ time curl http://localhost:8080/Table/testTable.seam > foo.seam
                     % Total % Received % Xferd Average Speed Time Curr.
                     Dload Upload Total Current Left Speed
                    100 55.1M 0 55.1M 0 0 1055k 0 --:--:-- 0:00:53 --:--:-- 756k
                    
                    real 0m53.694s
                    user 0m0.343s
                    sys 0m0.671s



                    JSP rendering took 9.5 seconds
                    JSF rendering took 53 seconds

                    I've made many runs with JSP consistently outperforming JSF by 5 times.

                    Tests were done on HP-A1130N PC.
                    I was monitoring memory usage (no excessive swapping)

                    JSF application is seam-gen generated (server side state saving,
                    standard configuration), JBoss from RedHat IDE.

                    These results are consistent with what I'm observing in our QA environment.

                    For similar table pages which would render in 1 sec we are getting responses in around 5 sec.

                    So performance of rendering tables is not sufficient.
                    Regards



                    • 22. Re: JBoss EL performance vs Sun EL
                      dustismo

                      We had similar issues with rendering large tables. The problem was fixed by simply outjecting the variables instead of accessing them through the bean.

                      So in you example try:

                      @Out
                      public String[][][] getData() {
                       return data;
                      }
                      

                      and in the view:

                      <ui:repeat value="#{data}" var="row" varStatus="index">
                      


                      hope that helps,
                      Dustin

                      • 23. Re: JBoss EL performance vs Sun EL

                        Thanks, we will try that.

                        However I think JBoss EL implementation has to be performance tuned anyway.
                        For a table I still would have to write

                        #{entity.property1}
                        #{entity.property2}
                        #{entity.property3}
                        #{entity.property4}

                        ...

                        and so on for each column.
                        And outjection doesn't help with these EL expressions.

                        Thanks


                        • 24. Re: JBoss EL performance vs Sun EL

                          My point with these code samples wasn't to write efficient code.
                          Actually it was quite opposite - write ineffifient code to create stress conditions so that ineffifiencies on internal implementation
                          EL/JSF/Seam would show up more clearly in profiler.
                          And that would help in fixing it.

                          Thanks

                          • 25. Re: JBoss EL performance vs Sun EL

                             

                            "dustismo" wrote:
                            We had similar issues with rendering large tables. The problem was fixed by simply outjecting the variables instead of accessing them through the bean.

                            So in you example try:

                            @Out
                            public String[][][] getData() {
                             return data;
                            }
                            

                            and in the view:

                            <ui:repeat value="#{data}" var="row" varStatus="index">
                            


                            hope that helps,
                            Dustin


                            I've tried that. It didn't help.
                            Same slow response times.



                            • 26. Re: JBoss EL performance vs Sun EL

                              Can you use cglib's fast method invocation in JBoss EL?

                              Thanks

                              • 27. Re: JBoss EL performance vs Sun EL
                                christian.bauer

                                Is there a particular reason why you refuse to use a profiler?

                                • 28. Re: JBoss EL performance vs Sun EL

                                  Yes. I don't have it right now.
                                  BTW:
                                  I've tried cglib FastClass and it is faster than what you are doing in JBoss EL
                                  ReflectionUtil.
                                  Thanks



                                  • 29. Re: JBoss EL performance vs Sun EL

                                    Well, if you don't have a profiler you should at least test EL performance only. Instead of building a tree of 1.000.000 components you could simply loop 1.000.000 times over a single EL evaluation (no ui component). That would exclude JSF from the list of suspects.

                                    Regards

                                    Felix