Page History

...

As of 5.0-alpha3, trees and lists are hardly usable, refreshing all the time, jumping up and down... So far this has even prevented us from completely dropping the old adminInterface module, because it is still much more usable, responsive. The goal of this concept is to analyze and highlight the performance hiccups in the magnolia trees and lists.

Tasks are also defined in the following parent ticket:

...

• Cause: This is due to the activation-status icon having a bigger font-size, introducing a bigger row-height.
• Effect: This is then likely to produce scroll jumps when the table is repainted, because this is based on calculated row height.
• Fix:CSS only.

  • Jira
    server Magnolia key MGNLUI-959

2. Tables set 'immediate'

...

• Effect: When getting down a big amount of nodes, at some point selection cannot keep up.
• Cause: That is because only a subset of rows (visible row count * cache ratio) has effectively been loaded (row-based lazy-loading).
• We don't need row-based lazy loading in trees.
  
  • There is already depth-based lazy-loading provided by the hierarchical container.
    
    • This ensures child nodes are loaded only when parent is expanded.
    • Chance is minimal to run into huge loading times when expanding.
      
      • JCR itself is not optimized for big flat data structures.
      • It was the same in old admin tree.
• How do I turn it off?
  
  • Row-based lazy loading is provided by the Table component.
  • Documentation tells to use setPageLength(0) to disable paging...
    
    • ... until client-side updates it automatically!
• Fix: Patch the Vaadin Table class to always use the getPageLength() getter from the class' internal code (no direct field reference).
  
  • This enables our TreeTable to override getPageLength() and return 0 all the time.

  • Jira
    server Magnolia key MGNLUI-961

• Some lazy loading might still occur when collapsing nodes down the hierarchy, but that's acceptable, given how tightly lazy loading is integrated within the Table component.
• There will be a new Table component in a future Vaadin version, but not by the time we ship 5.0.

...

• Effect: When comparing M5's config tree with a Vaadin prototype using the same JCR containers, there was still quite a big latency in the config tree when expanding a node.
  
  • Column widths are actually updated for all the table, when expanding/collapsing nodes!
    
    • Firebug clearly shows that table cells' width value is bouncing several times within 1-2 pixels of its original value; this is a very expensive CPU operation.
• Cause n°1: We set column's expand ratio systematically, even when it's not configured.
• Cause n°2: Table seems to send visible columns and their expand ratio even if values have not changed.
• Fix: First, do not set expand ratio systematically when building columns.
  
  • Maybe also Then patch TreeTable class client-side classes so that it not send visible columns and expand ratios again to client if they have not changed.does not repaint too many times, nor change column width according to max indent.

  • Jira
    server Magnolia key MGNLUI-962

6. Scroll position

• Effect: The tree might still jump slightly when expanding/collapsing nodes, just for the time it repaints.
• Cause: It is likely that there is some scroll position hack in connectors that we should assert how useful it is.
  
  • FOUND! line 138 in TableConnector: getWidget().updateFirstVisibleAndScrollIfNeeded(uidl);
    
    • was introduced with partial updates, see http://dev.vaadin.com/ticket/6722
    • it seems it can be removed , at least provided lazy loading is turned off.
  • It is documented in VScrollTable as /** For internal use only. May be removed or replaced in the future. */
    • as well as all other methods originating from legacy updateFromUIDL mechanism.
      
  • • with no visible effect (at least without partial updates).
• Fix: Patch TableConnectorto remove the call or VScrollTable to remove the body of that method.this call.

  • Jira
    server Magnolia key MGNLUI-960

Disculped

• It is interesting to note that our JCR containers are fine; they are not causing performance flaws.
  
  • Some methods however should be left unsupported since the container should be read-only, in other words, persistance is not managed by the container.
  • There is interesting insight on this in the Vaadin book section about SQL container.

...