Bug 61924 - [Presentations] PartStack creation slow on startup
Summary: [Presentations] PartStack creation slow on startup
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2004-05-12 11:38 EDT by Tod Creasey CLA
Modified: 2019-09-06 15:37 EDT (History)
2 users (show)

See Also:


Attachments
Optimize it output (54.29 KB, text/html)
2004-05-12 11:39 EDT, Tod Creasey CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tod Creasey CLA 2004-05-12 11:38:50 EDT
20040511-1600

Creation of the PartStack presentation takes 3.1 seconds on a workbench with 
the following state:

1) Workbench has platform-ui module loaded
2) No editors open
3) Only the resource perspective is opened 
4) Default views for the resource perspective

Note it is likely not as bad as that as the profiler affects this time. I will 
attach the trace
Comment 1 Tod Creasey CLA 2004-05-12 11:39:18 EDT
Created attachment 10549 [details]
Optimize it output
Comment 2 Stefan Xenos CLA 2004-05-12 12:31:05 EDT
Hmm... a good portion of that runtime was probably spent creating the view's
widgetry. 

The troubling part is that both ViewPane.createControl() and
DefaultPartPresentation.selectPart() are running slow -- only one of them should
be creating the view's widgetry.
Comment 3 Tod Creasey CLA 2005-03-07 11:57:24 EST
Adding my name to the cc list as we are now tracking performance issues more
closely. Please remove the performance keyword if this is not a performance bug.
Comment 4 Mike Wilson CLA 2005-04-21 14:57:38 EDT
Stefan, is this still happening? Is this PR still relevant? 
Comment 5 Stefan Xenos CLA 2005-04-21 17:08:24 EDT
This PR is rather vague, but it's still relevant. I'm working to speed up
PartStack creation on several fronts:

1. Reducing the number of widgets required for the default presentation
2. Speeding up the presentation layout
3. Reducing the number of times we need to create PartStack widgets
4. Reducing the number of parts that get activated by PartStack

There's different PRs for each of these issues. Number 4 has already happened,
number 3 will speed up perspective switches greatly but not startup, and layout
is already pretty fast (although we can still squeeze out some more cycles) so I
think the only remaining startup gain would come from 1... although I wouldn't
expect more than 20% improvement.

Besides making the parts themselves open faster, these are the only
optimizations I'm aware of. If anyone knows of other areas where PartStack could
be improved, please draw them to my attention.
Comment 6 Mike Wilson CLA 2005-04-22 08:59:06 EDT
If there are already PRs covering those cases, I would mark this one as a dup of the one that most 
closely matches it, since it really isn't adding a lot of value.
Comment 7 Paul Webster CLA 2006-09-28 15:13:29 EDT
Is this still a problem in 3.3?

PW
Comment 8 Mike Wilson CLA 2006-09-29 08:45:49 EDT
Is what still a problem? As it says in the comments for this bug, several optimizations could likely still be done, and they may be covered by other bugs.

If you're asking "Are we now fast enough at creating the PartStack presentation?", the obvious answer is "No, but maybe machines are fast enough now that I won't notice."
Comment 9 Denis Roy CLA 2007-06-22 09:32:38 EDT
Changes requested on bug 193523
Comment 10 Eclipse Webmaster CLA 2019-09-06 15:37:38 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.