Community
Participate
Working Groups
Build Identifier: Version: 4.2.0 Build id: I20120608-1400 Hi colleagues, we are using toolbar menu contributions pointing to a command like in following example: <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:mytoolbar"> <command commandId="mycommand" ... Our handler implementation of the command overrides the methods setEnabled and isEnabled to calculate the enabled state of the toolbar entry. This implementation is not very efficient and can take some time (backend calls needed). We had no problems with this implementation in eclipse 3.7. With Eclipse 4.2, we are now running into performance problems; it looks like that the setEnabled method is called all 400 ms which looks very strange. Why is this method called so often? Is there another mechanism/possibility in Eclipse 4.2 to contribute toolbar menu entries where the setEnabled method is called only then when it is necessary (when current focus/selection/part is changed)? With best regards, Tobias Reproducible: Always
toolbar enablement is checked on a timer currently. We're looking at a performance improvement for 4.3 PW
*** Bug 389251 has been marked as a duplicate of this bug. ***
We have a scenario where a PropertyTester is called repeatedly in 4.2 and it worked fine in 3.7 I assume this is caused by the same issue as this bug report.
The problem that we are facing for the property tester seems to be related to the setEnabled problem. The method E4HandlerProxy.execute is called recursively when a selection is made in the viewer.
Paul I don't know if it is priority in the current situation but we should really consider the RAT approach for this story. I was working on some other issue and this timer solution to the enablemenet switch is really a pain. Of course the RunAndTrack will need bug 387299 taken care of but Tom told me we would need Oleg to take a look at it.
*** Bug 389221 has been marked as a duplicate of this bug. ***
*** Bug 392565 has been marked as a duplicate of this bug. ***
This was introduced to for bug 340026. I had hoped to turn most requests into RunAndTracks which would keep them up to date, based on the parameters used by the @CanExecute method. But even in the test case from bug 340026 the tool item's enabled is determined from things not in the parameter list, so bug 396619 is not a viable solution. This will need more thought. PW
A timer-based solution is not acceptable for a normal platform contribution mechanism. If this is really required in special occasions, then there must be an explicit opt-in mechanism for those who want to pay the price.
*** Bug 360357 has been marked as a duplicate of this bug. ***
Replace the timer with updates tied to the IEclipseContext variables: https://git.eclipse.org/r/20715 PW
Released fix as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=8db6c323e9849920d98e722c437a1f531b97cbdd Timer is gone. PW
Thanks Paul. Just one clarification. How would I trigger the evaluation of the @CanExecute if the state of my tooltitems depend on non IEclipseContent variables? E.g. button "Load server data" should be active if new data on the server is available?
(In reply to Lars Vogel from comment #13) > > E.g. button "Load server data" should be active if new data on the server is > available? You'll have to open a new bug for that. For Eclipse4 in theory you can set the "org.eclipse.ui.internal.services.EvaluationService.evaluate" variable to Boolean.TRUE or FALSE on the MApplication IEclipseContext, but that's not been formalized and it probably should be. In the Workbench, re-evaluation can be requested using the IEvaluationService. PW
Thanks for this performance improvement. Just out of curiosity, do you use a tool or do you have a trick to measure the effect of such change on performance. I know there used to be some global performance tests, but I'm more interested in finding way to benchmark effect of an individual change.
(In reply to Mickael Istria from comment #15) > Thanks for this performance improvement. Just out of curiosity, do you use a > tool or do you have a trick to measure the effect of such change on > performance. We haven't done our performance pass yet (in the past we used yorkit) and our perf tests will hopefully be up some time in M6. This will remove the timer, the constant load on the CPU, and hopefully prevent bugs like bug 420310 :-) PW
*** Bug 420310 has been marked as a duplicate of this bug. ***
In 4.4.0.I20140120-2000 PW
CQ:WIND00-WB4-3452
