ICEfaces
  1. ICEfaces
  2. ICE-7667

ace:dataTable - slow sorting performance until tab change in IE

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.RC2
    • Fix Version/s: 3.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 3.0 RC1A Build 9/ICEfaces 3 trunk
    • Assignee Priority:
      P1
    • Affects:
      Compatibility/Configuration

      Description

      To reproduce in WPOC:
       - Load first tab with Screen 1 content.
       - Click on the retrieve button
       - Sort on a column. In IE it takes around 25 seconds for the sorted data to be displayed. Any sorts at the time will take around the same amount of time.
       - Add a new tab to the tab set via the "+" button.
       - Go back to Screen 1 tab.
       - Try sorting on any column, sorting now takes around 3 seconds for results to be displayed.

      Most of my testing was done in IE8 with IE7 document mode.

        Activity

        Hide
        Mark Collette added a comment -

        When the ace:dataTable is first sorted, every cell value changes, and the dom differencing will update them each individually, which is a little slow in most browsers, but quite slow in IE. Due to the caching, when changing tabs back and forth, there is no server side representation of the tab's contents any more, and with nothing to dom difference against, the full table is updated, which is a single update and is much faster.

        The solution seems to involve detecting these kinds of updates and forcing a full dataTable update instead of numerous piecemeal cell updates.

        1. This could be accomplished in the dom differencing algorithm itself, so that if a large table drastically changes, that would be treated differently than the large table slightly changing or a small table drastically changing. Once a sufficiently large number of updates have been found within a region of the dom, matching some heuristic which might even be tunable based on the browser, then the difference could stop comparing, and just ascend to a higher level and make a single replace update. This is the most automatic and fine grained solution. ICE-6600.

        2. Modify the ACE DataTableRenderer to detect that a sort or filter has occurred, and then force a full table update. This limits the behaviour to the ace:dataTable, so we don't get the benefit with compat or stock dataTables, and won't give the benefit when the app simply updates its contents. But it's the quickest and easiest solution. We can render a hidden div right inside the dataTable's top level div, that has no id and contains a counter value that increments on each sort or filter, which should preclude the table contents from even being differenced at all, and just update the whole thing. It's ham fisted, but will get the job done.

        3. We can accomplish #2 without the hidden div and counter if we had ICE-6601.

        Show
        Mark Collette added a comment - When the ace:dataTable is first sorted, every cell value changes, and the dom differencing will update them each individually, which is a little slow in most browsers, but quite slow in IE. Due to the caching, when changing tabs back and forth, there is no server side representation of the tab's contents any more, and with nothing to dom difference against, the full table is updated, which is a single update and is much faster. The solution seems to involve detecting these kinds of updates and forcing a full dataTable update instead of numerous piecemeal cell updates. 1. This could be accomplished in the dom differencing algorithm itself, so that if a large table drastically changes, that would be treated differently than the large table slightly changing or a small table drastically changing. Once a sufficiently large number of updates have been found within a region of the dom, matching some heuristic which might even be tunable based on the browser, then the difference could stop comparing, and just ascend to a higher level and make a single replace update. This is the most automatic and fine grained solution. ICE-6600. 2. Modify the ACE DataTableRenderer to detect that a sort or filter has occurred, and then force a full table update. This limits the behaviour to the ace:dataTable, so we don't get the benefit with compat or stock dataTables, and won't give the benefit when the app simply updates its contents. But it's the quickest and easiest solution. We can render a hidden div right inside the dataTable's top level div, that has no id and contains a counter value that increments on each sort or filter, which should preclude the table contents from even being differenced at all, and just update the whole thing. It's ham fisted, but will get the job done. 3. We can accomplish #2 without the hidden div and counter if we had ICE-6601.
        Hide
        Nils Lundquist added a comment - - edited

        This issue has been fixed by having the table force a full table DOM update following sorting or filtering.

        This can be optionally disabled by setting the config param "ForceFullTableDOMUpdates" to false.

        Changes made in r27222 and r27226

        Show
        Nils Lundquist added a comment - - edited This issue has been fixed by having the table force a full table DOM update following sorting or filtering. This can be optionally disabled by setting the config param "ForceFullTableDOMUpdates" to false. Changes made in r27222 and r27226

          People

          • Assignee:
            Mark Collette
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: