Community
Participate
Working Groups
Build ID: I20080208-1530 The caching in the CommonViewer is brittle and could behave differently depending on platforms (see bugs 197113, 144294, 140032). The only clean way to know the selection of a Tree is to ask it, which is expensive. There appears to be a significant performance issue with the use of the CommonNavigator in calling of getSelection() too often. Here is a snippet of a stack dump that indicates a possible area of performance improvement: at org.eclipse.ui.navigator.CommonViewer.getSelection(CommonViewer.java:416) at org.eclipse.ui.internal.navigator.resources.actions.PropertiesActionProvider$DelegateSelectionProvider.getSelection(PropertiesActionProvider.java:134) at org.eclipse.ui.internal.navigator.resources.actions.PropertiesActionProvider.setContext(PropertiesActionProvider.java:84) at org.eclipse.ui.navigator.NavigatorActionService.fillActionBars(NavigatorActionService.java:238) at org.eclipse.ui.internal.navigator.CommonNavigatorManager.selectionChanged(CommonNavigatorManager.java:219) Seems that setting up the actions is something proportional to the items selected and the number of action handlers. Since we know the selection higher in the stack, we ought to be able to convey this to the actions without too much trouble. I would be happy to work on a patch for this if people agree this is a direction we should take.
Yasser, I have opened this bug to try to solve the performance problem which motivated the addition of caching to the CommonViewer. For a bit of context, the addition of caching to the CommonViewer (bug 144294) had a problem (bug 197113). My feeling is that caching is a bad idea, because it's hard to get right on all platforms can could potentially break in the future with SWT changes, etc. Therefore, I'm proposing with this bug that we remove unnecessary calls to getSelection() in the CommonNavigator. I think doing this will solve your performance problem. Can you provide some additional data as to where the peformance problems you had were, if they were not in the stack trace that I provided? Thanks, Francis
Boris, You will see the message to Yassir above. This is in reference to the hallway conversation we had at EclipseCon. We need to understand exactly how Yassir is using the CN (what method(s) he's calling that are causing the problem) so that we can do a solution in the CN to improve performance so that it's acceptable to him. Can you get this information? Once I have this, then I can work on a patch to the CN that reduces the number of calls to getSelection() and then we can remove the caching and then fix the critical bug 197113 (which must be dealt with for 3.4).
The big items that call getSelection() are in filling the action bars and setting up the context menu. For the former, a selection provider can be given that uses a selection is currently available before the filling action bars starts. For the latter, the code can be changed to minimize the calls.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
