Bug 34865 - Debug config window real slow when many plugins
Summary: Debug config window real slow when many plugins
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P2 major (vote)
Target Milestone: 3.0 M2   Edit
Assignee: Wassim Melhem CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2003-03-12 15:38 EST by Richard Kulp CLA
Modified: 2003-06-16 10:09 EDT (History)
0 users

See Also:


Attachments
Fix for the bug (20.68 KB, application/octet-stream)
2003-03-12 16:27 EST, Richard Kulp CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Kulp CLA 2003-03-12 15:38:03 EST
Doing the following all result in 100% cpu for about 30 seconds.

1) When creating a new Runtime-Workbench configuration.
2) Selecting a Runtime-Workbench configuration from the debug config window.
3) Opening a debug configuration window where the last selected was a
Runtime-Workbench configuration.

They all have to do with a Runtime-Workbench configuration window showing up in
the debug configuration window.

I did a little debugging. It is in AdvancedLauncherTab.computeInitialState. It
has to do with the number of plugins in the target workbench configuration. I'm
debugging a WSAD workbench which has 755 plugins. It is acting like there is an
order(n-squared) algorithm in there.

I don't seem to be able to find the source for this class, so I can't tell what
it is doing, but as soon as it is finished with this method, the dialog comes up.
Comment 1 Richard Kulp CLA 2003-03-12 16:04:28 EST
I found the source and I know exactly where the problem is. The problem is the
CheckboxTreeViewer.setChecked on individual elements is extremely inefficient.
It needs to find the TreeItem associated with item to check and this requires
rebuilding the entire tree of TreeItems each time. In SWT the TreeItems are not
stored in the java tree, they are stored down in the Windows tree. To find an
item requires asking Windows (thru sendmessages) to return each individual tree
item one at a time.

It is much more efficient to gather everything that needs to be checked into a
collection and then use the setCheckedElements(Object[]). This will then create
the tree of items only once and as it walks it, it will check those that are in
the passed in array. 
 
Comment 2 Richard Kulp CLA 2003-03-12 16:27:53 EST
Created attachment 4077 [details]
Fix for the bug

In fact, I made the change I talked about and have attached it with this
comment.

You should of course verify that I didn't break anything, but the window nows
comes up with a more reasonable time.
Comment 3 Wassim Melhem CLA 2003-03-18 17:50:19 EST
Fixed.
Unfortunately, the suggested fix breaks several scenarios.

setSubTreeChecked(..) is pretty convenient and efficient for our plug-in tree.
It is now being used to initialize the state of the 'workspace plugins' subtree.

With 1024 external plug-ins and 20 workspace plug-ins, it takes me now 2-3 
seconds to create a new configuration on my 933MHz machine.
Comment 4 Richard Kulp CLA 2003-04-01 18:06:05 EST
It makes no difference on my machine. I'm using GA 2.1 and it still takes 30-40
seconds to bring up the dialog. I have 1Ghz machine.

Did you try it with the external plugins NOT checked? When I tried it with
external plugins checked, it worked ok, but when I tried with the external
plugins not checked, that's when it took a long time. We normally run with
external plugins NOT checked.

The problem is that individual unchecking takes just as long as individual
checking. You need to gather together all of those that need to be checked in
the external plugins and then just check those in one call to
setCheckedElements. Don't call setSubtreeChecked(true) first on the external
plugins; that's what causes the problem because it first quickly sets them all
checked, and then one by one unchecks them. (you can use the setSubtreeChecked
if it is found that all external plugins should of been checked, in that case
only you wouldn't need the setCheckedElements).

Thanks,
Rich Kulp
Comment 5 Wassim Melhem CLA 2003-06-16 10:09:10 EDT
Fixed. will be in tomorrow's I-build.
The problem was that the tree viewer was not set to use hash lookup when 
searching for elements, so it was taking a long time to locate the elements.

Now that it is using hash lookup, there is a huge improvement.