4 Replies Latest reply on Oct 26, 2007 5:08 PM by mgrouch

    Efficiency question

    dmitriy.lapko

      Can anybody please explain, how rerendering works? More precise, for what BaseXMLFilter is used.

      It looks like when a rerendering action is called on client side, the request is processed by this filter. It sends this request to a next filter and parses its response, extracts there elements, which should be updated on client side, packs them in response HTML and sends it.

      So, for example, if I have a big page with a lot of data and I want to update only one little part of it, according to this scenario the whole page will be rerendered + parsed with Tidy parser and only my little part would be returned.

      Is it correct? If yes, then rerendering is not so great feature as it looks like for me now. I hope, that on rendering phase only asked elements of the tree are rendered, or at least not the whole document is parsed but only asked elements are found and extracting without unnesessery parsing of all nested or sibled elements...

      Why do I ask this? Because I'm profiling my JSF application with a lot of ajax4jsf rerendering feature, and I see in logs:

      Parsing html total time 37219ms

      and total response time: 99 seconds, render response phase tooks 34 seconds.

      So, I want to update only one little part but because of rerendering of everything and parsing of everything I get 70% of wasted time.

        • 1. Re: Efficiency question

          I have same question. Why on AJAX requests does it parse html again?
          In my case it is taking more than 50% of render phase.
          It further complicates JSF performance issues.
          Is it because I use some tags from richfaces which are not closing elements
          properly and produce malformed html or there are some other reasons?

          Can you define in the documentation clearly the cases when tidy can be turned off completely and when it can be replaced by nekohtml?

          Thanks

          • 2. Re: Efficiency question
            dmitriy.lapko

            Hallo mgrouch,

            I watched your discussions in JBoss Seam forum concerning performance issues, I have the same problem and I'm trying to solve it. Do you have any good news about it?

            So, did you manage to speed up your application which generates big dataTables and use a lot of EL?

            If not, which ways of refactoring can you recommend for this case? For example, may be it makes sense to evaluate an expression, store it in some context like Page or Event and then reuse it in other expressions - this can solve problem with switch statement... Or, for example, not use dataTable but just ui:repeat...


            • 3. Re: Efficiency question

              We ended up creating own JSF table component in Java using JSF API.
              We also do not use any reflection at all to access bean properties while rendering table.
              Table takes list of entites as argument as well as metadata object for the table. This metadata object contains list of column metadata
              (type of bean property, filter condition if user filters by that column,
              flag if sorting is allowed, type of the filter, property accessor object (non reflective), style classes, etc). There is an abstract class metadata.
              You implement this class separately for each table (bean type which you use in table). You implement getId(bean) method by overriding it,
              so getId is not relying on @Id annotation reading and reflection.

              This gave us the following features for table (and full control)
              1. Sortable (with Ajax actions on headers)
              2. Groupable (multiple client-side collapsible expandable tbody in html table). Each group sorts on its own like in Woodstock's (or ExtJS) group table.
              3. Customizable filters in column headers (via column metadata)
              4. Ajax Pagination within groups
              5. Fully customizable group header
              6. Ability for user to change column order and choose which columns are displayed as well as saving this configuration in user preferences.
              7. It renders fast as it simply equivalent to looping via columns and rows and producing output in Java (no EL, no reflection, no annotation reading)
              8. The implementation is quite generic. Application which used bass classes
              for the table only need to override few methods in few classes (as table metadata), and pass these classes objects to table tag.


              Since java doesn't support method references (until Java 7)
              property accessor looks like this

              public interface PropAccessor<B, V> {
              
               V get(B bean);
               void set(B bean, V value);
              }


              (Yes it is one class per property):

              public class CarPropAccessor {
               public final static class CarModel implements PropAccessor<Car, String> {
               public final String get(Car bean) {
               return bean.getCarModel();
               }
               public final void set(Car bean, String value) {
               bean.setCarModel(value);
               }
               };
              ...
              more accessors for Car properties
              }



              This code can be generated by hibernate tools using freemarker template
              so no need to write it for each bean you are using.

              As for performance:

              It renders fast without Ajax, but on Ajax requests RichFaces reparses it and we see big losses (we haven't solved it yet).

              We noticed by doing profiling that Seam/JSF/Ajax4Jsf combo has performance losses in the following areas (during rendering phase):

              1. EL evaluation (reflection, EL is not compiled in byte code ...) - JBoss EL
              2. Annotation reading (things like isAnnotationPresent etc, JDK annotation reading implementation is not fast) - Seam
              3. Interception - Seam
              4. On Ajax HTML parsing in RichFaces response filter (And using nekohtml
              breaks it). Causes big performance degradation - RichFaces
              5. Other thirdparty libraries also install own post/'while' rendering processing.
              (Ex: Quipukit validation framework when enabled)





              • 4. Re: Efficiency question

                and more

                RichFaces are supporting JDK 1.4 so they use StringBuffer instead of
                faster StringBuilder

                It would be nice to have JDK5 version of RichFaces with JDK5 optimizations.