Community
Participate
Working Groups
The last time I profiled switching perspectives, a large portion of the time was spent re-creating the presentation widgets. We could improve the time to switch perspectives by about 40% if we cached the widgets for the last 3 opened perspectives rather than destroying and recreating them every time.
Heap usage would be a concern here? Is it the actual creation of the widgets or layout, menus etc... being calculated that take time?
move performance to keyword field
It's the creation of widgets. The CPU time is being spent in PartStack.createControl(), and this is the call we'd avoid by caching. (Well, there's also optimizations we can make to building menus, etc... but I've filed separate PRs for them.) Of course it would also have a cost in heap space, but if we only cache a (small) constant number of perspectives, the cost shouldn't be too bad.
see bug 27179
As usual, we need to think about both time and space performance. How much space are we talking about?
Created attachment 21078 [details] Implements this optimization Implements this optimization. I don't want to commit this until I've tested it more, but I'm attaching it here so that anyone who is interested can confirm the my claims about heap and CPU usage.
Created attachment 21079 [details] Fixes internal references that have changed (ui.tests)
Created attachment 21080 [details] workbench patch Oops... attached the wrong patch above
Created attachment 21081 [details] Performance logs It looks as if the performance improvement is pretty impressive. Keep in mind that these comparisons were done against the code in head, which is aleady 70% faster than Eclipse 3.0 (according to the automated tests). In optimize-it, the time spent in WorkbenchPage.setPerspective was reduced from 222ms to 101ms (54% improvement). I also tested with the performance suites (console logs attached). Here's some of the highlights. Times are shown as (old time / new time / %improvement): perspective switching: java/debug: (447 / 232 / 48%) performance1 / performance2: (168 / 75 / 55%) dragdrop / fastview: (119 / 76 / 36%) java / empty: (226 / 171 / 42%) resource / java: (416 / 261 / 37%)
Just started testing this -- there are definitely bugs still. ;-)
speed to switch perspectives has improved but what about memory and handle usage? I'd like to see this running on MacOS or GTK to see the impact of keeping what amounts to an extra perspective page or two worth of widgets etc... around.
Re: comment 11 I can only do so much in a day. I originally estimated that this code change would take a week, and its now almost finished after one (very long) day. I will get some memory numbers ASAP.
Heap cost is approx 17k per perspective (the default Java perspective uses 674k, so this is approx. a 3% increase).
Fixed in head.
My goodness! Does anyone else think 674K for one perspective is a lot?
I'm including the memory used by the views themselves, and I measured this on a "real" workspace, so I'd expect the problems view and package explorer to be using a fair chunk. I measured the memory increase for opening the Java perspective for the first time when the debug perspective was active.
Looking at a sampling of the performance results for I20050808-0800, it seems that this patch (at least in part) has contributed to some significant performance improvements for perspective switching.
More accurately, this patch is almost solely responsible for significant performance improvements, as evidenced by my own test results (above) and tod's tests when he experimented with rolling this back.
Would you please look at bug 108033? I think this broke the persistence of the view tab orders between workbench sessions...
*** Bug 27179 has been marked as a duplicate of this bug. ***
