Community
Participate
Working Groups
In Bug 549171 it has been explained how to improve performance for bulk insert and deletion. One part of this optimization can be taken over as generic approach. That is the setRedraw(false) call within removeAll() of a TreeView. As the cost of the forced redraw for small amounts of elements outweights the saved calls within the loop we should stay away from this optimization for a number of elements below 30. This is an estimation based on some tests using Bug548982_TreeAddRemoveMany.java using some different values for NUM_ITEMS.
I expect to merge this patch tomorrow. By the way, can you please tell which problem are you solving? Is this a problem in Eclipse or some other SWT based software?
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/165852 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=bd6c66bfe56580a4d962ef167bb8eaff1f3be166
In master now. Carsten, thanks for working on this!
Carsten, if by chance you're willing to do more improvements here, I know how to improve performance of 'TreeItem.removeAll()' a lot more - by using `TVE_COLLAPSERESET`. If you're willing to implement that, it would be great!
Thanks Carsten.
(In reply to Alexandr Miloslavskiy from comment #4) > Carsten, if by chance you're willing to do more improvements here, I know > how to improve performance of 'TreeItem.removeAll()' a lot more - by using > `TVE_COLLAPSERESET`. > > If you're willing to implement that, it would be great! Thanks for your support! I guess I first have to understand a few components a little bit better.
Verified in I20200818-0900 (using test snippet 'Bug548982_TreeAddRemoveMany'): The patch works as expected. When user's code does not explicitly request `setRedraw(false)`, there is roughly a 3x speedup (11771ms -> 3653ms) for `TreeItem.removeAll()` with 20000 child items.
