Community
Participate
Working Groups
Build F3 Since upgrading to F3, I've found that opening the PDE Manifest editor has become unbearably slow. Opening the plugin.xml file for my project takes in excess of 5 minutes! (This is on a 2GHz machine with 512MB of RAM!) My plugin has a large list of pre-reqs and no dependent plugins. Many of the pre-reqs exist only on the file system (i.e. they're external JARs, not projects).
Once the manifest editor opened, it took >1 minute to switch from the Overview page to the Dependencies page.
Are you using a non-default option (pointing to a target platform different than the plaform you use for development)? If you are, you are getting the behaviour of the Core registry resolver. If using the default option (this application), I am populating the model from the 'live' registry and should take less time.
Indeed I am. My development install is in d:\eclipse and my runtime install is in d:\wsadie50-build\eclipse. Note that switching to the dependencies page actually seems to take about as much time as opening th editor in the first place (my initial 1 minute estimate was inaccurate). It's probably repeating the work that was done to open the editor.
It is very hard for me to make a quick optimization when design and run time instances are not the same. When they are, I can use the live registry and avoid paying the price of parsing 300 plug-ins. Otherwise, I must do what the registry is doing on startup, only with much less RAM because I am doing it while one Eclipse instance is already up. Post 2.0, we may investigate reworking PDE to use an indexer like JDT and build up its model in the background while the system is idle.
I think that something else is going on here. Other plugin.xml files open very fast. It's just the one which takes 5 minutes.
Adding a required plug-in takes about the same amount of time. My 2GHz CPU is at about 90% all this time, so it's not IO bound. (This means that the process of adding a required plugin takes in excess of 15 minutes, since it takes 5 minutes to open the editor, 5 minutes to switch pages, and 5 minutes to add the plugin.)
Note that this plugin doesn't seem to have the PDE nature, for some reason. The 'Update Classpath' option is missing from its context menu. But if I 'Update Classpath' from another project, I can select my project, instead.
I've added the PDE nature and builders to the project by hand. This did not affect the time to open the editor, but it did fix the 'Update Classpath' problem. I've also verified that the problem exists for other team members, as well. i.e. it's not just some quirk about my configuration. Karice clocked opening the manifest editor at 210sec.
Peter Dejan/DJ Are you sure that the same problem does not exist in F2? What changed between then an now in either your setup or in PDE/Core.
I don't remember seeing the problem in F2, but Karice believes that the problem has been around since at least F2.
I have seen the problem in F2 (takes over 3 min) and in the 0521 build (takes about 1.5 mins). I haven't been able to replicate the problem in 0416, but the plugin.xml looked quite different then.
97% of the time is being spend in DepenencyLoopChecker.findLoops(). From reading the code it does not appear that you actually need to know all of the loops because you only check to see if there is one. The alogorithm for this is a simple tree walk O(n) instead of the complex algorithm you are currently using. There are other places that would benefit from this optimization as well.
The reason for this problem is in linear search for plug-ins using their IDs in the routine. The routine is recursive and plug-ins are looked up using their IDs many times. Linear lookup is performed each time. When there are 400 plug- ins, things get slow quickly. Proposed fix is simple and effective: PDE has 'uber' model manager that is simply a hashtable that represents what PDE sees as the 'plugin path'. This table contains entries whose keys are plug-ins IDs. Each entry contains reference to the workspace plug-in with the key ID (if present) and external plug-in with the same ID (if present). When asked to provide plug-in for the ID, entry returns workspace (if not null), or external. This model manager has been added relatively recently in order to solve problems with duplicates in plug-in paths and to drive Plug-ins view. By asking it to return a plug-in given the ID, we are using the hashtable instead of the linear search. Fix is very simple and dramatic - what takes minutes now takes only seconds. The fix is in a well encapsulated class (DependencyLoopFinder) and only affects loop detection (it is tempting to perform similar fix in other places where findPlugin method is called, but it is only in loop finder that the fix gives such a dramatic difference).
Fixed.
