Bugzilla – Full Text Bug Listing
| Summary: | [performance] Switching views: 30% of CPU goes on toolbar re-layout | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Oleg Besedin <ob1.eclipse> |
| Component: | UI | Assignee: | Oleg Besedin <ob1.eclipse> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ob1.eclipse, pwebster, remy.suen |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
There are several points to consider in there: 1) Do we really need to use active leaf context? Could we use context of the toolbar container instead? 2) Can we limit calls to ToolBarManager#update() to cases where we actually had some visibly changed? 3) We have multiple RaTs that are getting called more than once for every view switch. It seems that while debugging SDK I get about 10 RaTs each called 3 - 5 times. Both of those numbers seem high. I made a patch and discovered that Remy fixed this on Thursday in bug 370337. Well, great minds think alike :-). *** This bug has been marked as a duplicate of bug 370337 *** (In reply to comment #2) > I made a patch and discovered that Remy fixed this on Thursday in bug 370337. Go, go, performance fixes! :) |
Testing switching between views, I noticed that about 30% of the time goes into toolbars being recreated. The trigger point is: ToolBarManagerRenderer private boolean processAddition(final MToolBar toolbarModel, ... ... parentContext.runAndTrack(new RunAndTrack() { ... record.updateVisibility(parentContext.getActiveLeaf()); manager.update(true); ... Those RaTs use #getActiveLeaf() and, hence, are called every time active part changes. The call to ToolBarManager#update() disposes and re-creates the toolbar. To reiterate, this code causes each and every toolbar to be completely re-created on every change in the active part, possibly more than one time, regardless of where any visibility changed occurred in toolbar elements.