| Summary: | An IContributionManagerOverrides's getVisible(*) method is called 2k-10k times | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Remy Suen <remy.suen> | ||||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, dean.t.roberts, deepakazad, emoffatt, melickm, ob1.eclipse, pwebster, yevshif | ||||||
| Version: | 4.2 | Keywords: | performance | ||||||
| Target Milestone: | 4.2.2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Remy Suen
The number varies greatly but some items get called over 160 times. WorkbenchPage's updateActionSets(*) method seems to be the problem. It gets at least five or six times slower when we apply the patch from bug 320478. The problem probably lies in the fact that we have to activate and deactivate contexts individually. This means that context changes are made incrementally instead of in a batch, compounding the number of change operations required for showing and hiding action sets. (In reply to comment #2) > The > problem probably lies in the fact that we have to activate and deactivate > contexts individually. This means that context changes are made incrementally > instead of in a batch, compounding the number of change operations required for > showing and hiding action sets. I tried batching the changes and while it's cut the time by more than half, the method is now called 3k-5k times (higher minimum, much lower maximum). (In reply to comment #3) > I tried batching the changes and while it's cut the time by more than half, the > method is now called 3k-5k times (higher minimum, much lower maximum). Further changes in MenuManagerRenderer and ContributionRecord brings it down to the 1k range. Created attachment 210396 [details]
Menu contributions patch v1
This patch changes the menu managers to not get updated so aggressively.
Created attachment 210400 [details]
Context patch v1
This patch batches the context change operations. Though it's not clear to me if it's actually in line with what deferUpdates(*) is supposed to do or not.
(In reply to comment #5) > Created attachment 210396 [details] > Menu contributions patch v1 The same change should also be applied to ToolBarManagerRenderer. (In reply to comment #7) > The same change should also be applied to ToolBarManagerRenderer. Paul has given me the OK. Both renderers and contribution records have been updated. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=990da1fcd2b8588a64bae4cf7efb1f2f156583f3 *** Bug 370758 has been marked as a duplicate of this bug. *** (In reply to comment #2) > WorkbenchPage's updateActionSets(*) method seems to be the problem. It gets > at least five or six times slower when we apply the patch from bug 320478. > The problem probably lies in the fact that we have to activate and > deactivate contexts individually. This means that context changes are made > incrementally instead of in a batch, compounding the number of change > operations required for showing and hiding action sets. The context changes are now all batched, we're down to about ~150 for active part changes. PW (In reply to comment #10) > The context changes are now all batched, we're down to about ~150 for active > part changes. > > PW Verified in N20130122-2000- |