Description Michael Keppler 2018-10-02 07:44:39 EDT

ContainerCheckedTreeViewer has really bad performance (at least on Windows).

Real world reproduction steps:
* Open a target platform editor (with some hundred plugins in the target platform, as for a typical eclipse.org project) and wait for the platform to resolve.
* Switch to the "Content" tab.
* Enable "Group by location". Application is blocked for several seconds (specific measurement: the egit-4.6 target editor is blocked for 24 CPU seconds on my machine, according to Yourkit)
* start typing in the filter text above the tree. After each character the application is blocked for several seconds again.

Root cause analysis:
* setCheckedElements(...) sets all the currently checked checkboxes after each UI change. that is fine.
* it calls doCheckStateChanged(), which in turn updates all parents, updates all children, and accesses all siblings of each item. Each of those operations needs 1 to 3 calls into the operating systems native widgets to get the checked/grayed state of the checkbox
* In practice for a tree with all (or almost all boxes checked) that leads to a runtime near O(n^2) on every call to setChecked(...), and the CPU time is bound by the window system calls for getting the items and their state.

The optimization approach is rather simple: Stop iterating the child and parent hierarchies when the checked/grayed state of the current item does not change.