DisplayTag
  1. DisplayTag
  2. DISPL-380

Very poor performance on bigger list or bigger <display:table> tag content

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: Tag Library
    • Labels:
      None

      Description

      When the list to display is average (in my case ~2000) and there is big content of <display:table> preformance is very poor: ~40 second to display 20 results out of 2000.
      I dig out and now see the way to improve it.
      Scenario
            <display:table contains some logic + display:columnt tags:
      <display:table id="oc" name="results" pagesize="${pagesize}"
      requestURI="${request.contextPath}" sort="list" defaultsort="1">

      <!-- some logic here about 20 logic tags - very needed -->
      <logic:iterate id="attr" name="x" property="b">
      .....
      <display:column property="a"
      ....
      />
      </display:table>

      Obviously the display:table iterates its content through whole list - so all the tags are evaluated list.size() times. And it is very time consuming. doAfterBody called on TableTag in loop takes 38 seconds and real display of table (doEndTag) 2s in my case.

      In fact it is enough to iterate the body of display:table ONCE, build the column structure and do the job in doEndTag. It will improve performance dramatically in such cases.
      The only difference is that there cannot be any code inside which depends on the current row (for example getting the value from row and using it in anyway.

      To keep compatibility, new flag can be added: evaluateBodyOnce [boolean] (or buildColumnStructureOnce) to switch from every-row-body-evaluation to one-time-body-evaluation.

      (Now to improve performance a little bit, partialList can be used, but there is a lot of code to write addtionaly - to sort, to tract offset, etc).

        Activity

        Hide
        Wolfgang Schmiesing added a comment -
        I agree with Tomasz and am facing a similar performance issue. I have a <display:table> tag that includes 9 <display:column> tags. One column tag includes a simple iteration over up to 5 values, two others a simple if-then-else construct. The rest is plain display of values. When I leave out the columns with iteration and cond. logic display is 4 times faster.
        The difference to the Tomasz' scenario is that my column logic does depend on the current row. However, it does not need to be executed each time when the list is re-displayed but only once. I also think that this is true for most use-cases when the whole list is kept in memory.
        Thus, it would be nice to be able to evaluate the column logic once instead of every time the list is re-displayed.
        Show
        Wolfgang Schmiesing added a comment - I agree with Tomasz and am facing a similar performance issue. I have a <display:table> tag that includes 9 <display:column> tags. One column tag includes a simple iteration over up to 5 values, two others a simple if-then-else construct. The rest is plain display of values. When I leave out the columns with iteration and cond. logic display is 4 times faster. The difference to the Tomasz' scenario is that my column logic does depend on the current row. However, it does not need to be executed each time when the list is re-displayed but only once. I also think that this is true for most use-cases when the whole list is kept in memory. Thus, it would be nice to be able to evaluate the column logic once instead of every time the list is re-displayed.
        Hide
        German Ruiz added a comment -
        I have the same problem. When I export large list (about 50.000 elements), I have memory errors.
        I solved it (partially), sharing the instance of HtmlAttributeMap along all cells in the same Column. To do this, I modified the class ColumnTag using the last version in HEAD.
        Show
        German Ruiz added a comment - I have the same problem. When I export large list (about 50.000 elements), I have memory errors. I solved it (partially), sharing the instance of HtmlAttributeMap along all cells in the same Column. To do this, I modified the class ColumnTag using the last version in HEAD.
        Hide
        German Ruiz added a comment -
        Modification on ColumnTag as I described in previous comment.
        Now, I think that my problem isn't the same as of the original issue. But I tried to minimize object allocation to don't have an OutOfMemoryException.
        Show
        German Ruiz added a comment - Modification on ColumnTag as I described in previous comment. Now, I think that my problem isn't the same as of the original issue. But I tried to minimize object allocation to don't have an OutOfMemoryException.
        Hide
        German Ruiz added a comment -
        I delete my patch because have an error when the class/style change between differents rows for the same column.

        So, Can I omit instanciate HtmlAttributeMap when the currentMediaType is HTML?
        Show
        German Ruiz added a comment - I delete my patch because have an error when the class/style change between differents rows for the same column. So, Can I omit instanciate HtmlAttributeMap when the currentMediaType is HTML?

          People

          • Reporter:
            Tomasz Bech
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: