Abstract
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.
Main factors
- Rows have different heights
- This is due to the activation-status icon having a bigger font-size, introducing a bigger row-height
- This is then likely to produce scroll jumps when the table is repainted, because this is based on expected row height
- The fix is CSS only.
- This is due to the activation-status icon having a bigger font-size, introducing a bigger row-height
- Tables are set immediate
- What immediate means for Vaadin components is that value changes are immediately propagated to server.
- For tables, the value is the selection, so every time one presses an arrow key and changes selection, we get a server roundtrip, seemingly repainting the table.
- However, the drawback of setting tables non-immediate is that location fragment in the URL is no longer updated as soon as selection changes, but in the next roundtrip.
- We did this because location is controlled on the server
- But wait! Browser location is definitely a client-side thing.
- Can the MagnoliaShell's client side update the location fragment without going to the server?
- How would that look dependency-wise, knowing that we deal with
ContentLocation
, from the content-app module?
- What immediate means for Vaadin components is that value changes are immediately propagated to server.
- Row-based lazy loading for trees
- When getting down a big amount of nodes, at some point selection cannot keep up.
- That is because only a subset of rows (visible row count * cache ratio) has effectively been loaded.
- We don't need lazy loading for 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.
- There is already depth-based lazy-loading provided by the hierarchical container.
- 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!
- How about using setCacheRatio(10000), loading up to 10,000 times the number of visible rows. It might be enough?
- Damn, there is still some lazy loading occurring when collapsing nodes down the hierarchy
- When getting down a big amount of nodes, at some point selection cannot keep up.
- Partial updates
- Vaadin TreeTable normally supports partial updates if container is an
ItemSetChangeNotifier
(not sure why)...- ... but this is currently disabled with
// FIXME: This disables partial updates until TreeTable is fixed so it
does not change component hierarchy during paint
- This needs to be clarified by the Vaadin guys, forcing partial updates seemed to work basically fine.
- ... but this is currently disabled with
- This is not the most harmful factor for user interaction, but it might have a significant impact when many nodes are expanded.
- Inplace editing is not yet using partial updates, although that was done in the standalone PoC (ticket already exists).
- Vaadin TreeTable normally supports partial updates if container is an
- Config tree is still slow
- When comparing M5's config tree with a Vaadin prototype using the same JCR containers, there is still quite a big latency in the config tree when expanding a node.
- Try without config app's inplace editing (uses a field factory) => no significant improvement
- Try without MagnoliaTable / TreeTable => no significant improvement
- Try without cell style generator => no significant improvement
- The tree seems to repaint (scrollbar flickers a bit) several times more than in the prototype (scrollbar might blink once at all).
- Investigate whether MagnoliaTable/TreeTable does explicit repaint, refreshes row cache, or forces layout again.
- When comparing M5's config tree with a Vaadin prototype using the same JCR containers, there is still quite a big latency in the config tree when expanding a node.
- Collapsing can still jump
- -
Remarks
- 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.
- Some methods however should be left unsupported since the container should be read-only, in other words, persistance is not managed by the container.
- Vaadin Table is too tightly coupled with lazy data model mechanism - there should be a way to disable page buffering mechanism entirely.
- There will eventually be a new Table component in a not-so-soon future Vaadin 7 version
Proposal
-
Decision
- Fix variable row height
Overview
Content Tools