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 dev.vaadin.com. You can add me as a cc, I can try to press the issue forward for investigation to our core team.
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…