TreeTable performance degradation recently ?

I’m not quite sure how recent the performance proplem is ( or if is simply that the data hit some threshhold recently ), but I’m sure we used the treetable with 100 items in the last six months without problems…

itemContainer.addAll(values) ItemContainer is a customized version of a BeanItemContainer ( so it will get wrapped a ContainerHierarchicalWrapper )
Info: Document loaded 119 lines in 2,790 ms
Not great but I’ll take the 3seconds.

But then we build a simple hierarchy (a slightly simplified version of what I do).

for (DocumentLine line : itemContainer.getItemIds()) { treeTable.setChildrenAllowed(line, false); treeTable.setCollapsed(line, false); if (!isComment(line)) { treeTable.setParent(line, prevComentLine); } else { treeTable.setChildrenAllowed(line, true); prevComentLine = line; } } Info: Document processed 119 lines in 178,304 ms,
130x setChildrenAllowed() 2 ms
119x setCollapsed() 96,480 ms
95x setParent() in 81,821 ms

I would put my money on Table.getVisibleItemIds() as the culpret for setCollapsed() here…
but the setParent in the ContainerHierarchicalWrapper ?

I’m sure I can optimize the the above code a bit , but the point is this code is unchanged for quite some time and only now (7.4.x ) start to give performance issues. I was on 7.2 before this…

Has anyone else noticed this ? or have you all moved over to the Grid ?

There are lots of features that are still missing from Grid (including a “TreeTable version”), so I bet most people are still using Table. The performance regression seems rather bad to me so I’d really suggest to create a ticket about it to You can add me as a cc, I can try to press the issue forward for investigation to our core team.


I reworked the existing code a bit.

treeTable.refreshRowCache(); before the loop and made use of the default BeanItemContainer and a GeneratedPropertyContainer to make the custom value property. This improved things considerably, so my Custom Bean Container + internal item&property implementaion (originaly based on vaadin 6) did add a lot of the pervious time. But ContainerHierarchicalWrapper is still a problem once the data size increase with an order of magnitude ( x30 ).

With the same 119 lines the times are down to:
Info: Document loaded 119 lines in 1 ms ← this improved from 2700ms
Info: Document processed 119 lines in 83 ms, ← this from 170000 ms
setChildrenAllowed:0 ms,
setCollapsed:31 ms,
setParent:51 ms

Increasing the items to ± 3000 lines is still a problem(though in our case we will very seldom display so many items, the data I uses was the worst case I found in the database.).

Info: Document loaded 2,887 lines in 5 ms
Info: Document processed 2,887 lines in 107,633 ms,
setChildrenAllowed:13 ms,
setCollapsed:748 ms,
setParent:106,850 ms ← this still indicates a order n^2 operation on the item id’s it would seem.

Once the data is loaded though the client side handles the treetable without difficulty.
I’ll make a reproducable sample and submit a ticket…

Added a ticket
But I could not add you as a cc ( only seems to allow to add myself or I missed something. )