Community
Participate
Working Groups
The HandlerSelectionFunction#compute() [org.eclipse.ui.internal.handlers.LegacyHandlerService] takes up over 50% of the CPU time when opening/closing views. There are about 800 calls to this method per cycle of { open view, close view } in the SDK.
The last part of HandlerSelectionFunction#compute() does not seem to be needed: // "super call" IEclipseContext parent = context.getParent(); if (parent == null) { return null; } return parent.get(HandlerServiceImpl.H_ID + commandId); It seems to me that not only it uses up a bit of extra CPU, but also results might be incorrect. For instance, if I am a dialog that does not have a handler for "paste", but my parent is an editor that does have a handler, then "paste" contents instead of the dialog will go to the editor. Paul, is that desirable?
(It was added in the bug 318930 )
Correction: when writing the bug I used results from profiler. In some cases those results get skewed by profiler instrumenting the code. Check with direct calls to System.nanoTime shows that HandlerSelectionFunction#compute() uses about 25% of the time in the {open view, close view} sequence.
(In reply to comment #1) > IEclipseContext parent = context.getParent(); > if (parent == null) { > return null; > } > return parent.get(HandlerServiceImpl.H_ID + commandId); > I'm not sure why it wouldn't just be "return context.get(HandlerServiceImpl.H_ID + commandId);", unless there originally was a conflict between a handler and a List of handlers at that ID. PW
Also this code in PartSite: private void initializeDefaultServices() { IHandlerService handlerService = new LegacyHandlerService(e4Context, new ActivePartExpression(part)); This creates a default "And" expression for every handler that says that it is available for the given part. However, the handler is added to the context of the part. So, for every 3.x construct the "And" expression won't be needed, unless there are other bugs in the code. It only could play a role for 4.x-style nested parts, and then it is not clear if the behavior it creates will be a desired behavior. (Logically, this will disable any handlers specified on the 4.x-style "container" parts which is probably not what we want). What if we change this to: IHandlerService handlerService = new LegacyHandlerService(e4Context, null);
(In reply to comment #5) > What if we change this to: > > IHandlerService handlerService = new LegacyHandlerService(e4Context, > null); I added this code to fix bug 355118. The bug does not come back if 'null' is passed.
Similarly to the comment 5, the default expression created in LegacyHandlerService(IEclipseContext context): defaultExpression = new WorkbenchWindowExpression(window); should not be necessary.
Created attachment 209935 [details] Main Menu visibility should not care about menu item enablement v01
I've released an incremental improvement to switching parts: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=92f1e719d4d47017dd15c5ff4705b64870fdda69 PW
Released http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b31b27014f607553b86c22b01d95616f142d2260 try and only run EvaluationReferences when the variable of interest: value changes. PW
Using current code base, HandlerSelectionFunction#compute() takes about 7% of the time in the open view / close view cycle.
(In reply to comment #11) > Using current code base, HandlerSelectionFunction#compute() takes about 7% of > the time in the open view / close view cycle.
