Bug 330943 - [plug-in registry] View initialization takes too much time
Summary: [plug-in registry] View initialization takes too much time
Status: RESOLVED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 3.7 M4   Edit
Assignee: Curtis Windatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks:
 
Reported: 2010-11-23 12:15 EST by Wojciech Galanciak CLA
Modified: 2010-11-24 14:48 EST (History)
6 users (show)

See Also:

Attachments
patch (1.67 KB, patch)
2010-11-23 12:19 EST, Wojciech Galanciak CLA 		no flags Details | Diff
updated patch (1.42 KB, patch)
2010-11-23 15:17 EST, Wojciech Galanciak CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Wojciech Galanciak CLA 2010-11-23 12:15:27 EST 
Initialization of Plug-in Registry view is very slow, especially when a number of plug-ins is high (e.g. >400).
Comment 1 Wojciech Galanciak CLA 2010-11-23 12:19:54 EST 
Created attachment 183684 [details]
patch

This patch increases speed significantly. Here are some results for two different target platforms:

1) 197 plug-ins
Current:
7155
With patch:
648

1) 441 plug-ins
Current:
19535
With patch:
1478

I have tested it and there are not any regression problems.
Comment 2 Curtis Windatt CLA 2010-11-23 12:40:58 EST 
Looking at the patch, I found it very surprising to see that the performance difference is so significant.  The search being done in the patch is essentially the same as what is done in the state.  However, it appears that asking the platform admin for the state actually creates a new State each time it is called.  Even though it is based on the current state, the method has to create new bundle descriptions for each bundle.

cc'ing Tom for comment.  It feels like PlatformAdmin should mention in the javadoc that it creates a new state.  

Is there a way to get the cached system state?  I don't see anything wrong with the patch asking the bundle context for the current bundles, but if we have a state, it would be better.
Comment 3 Wojciech Galanciak CLA 2010-11-23 15:17:07 EST 
Created attachment 183705 [details]
updated patch

It looks like the problem can be also solved in a different way. Curtis, you are right that method PlatformAdmin.getState() creates new state for each call. The cause we request for a mutable state. If we need to get a state only for reading (in our case) we can call PlatformAdmin.getState(boolean) with false and then we do not create a new state object. I have attached a patch. It makes the same improvement as a previous one.
Comment 4 Curtis Windatt CLA 2010-11-24 14:48:31 EST 
Fixed in HEAD.  Thanks for the patch!