Community
Participate
Working Groups
I've noticed that opening and switching perspectives is slow with the base Eclipse 2.0.2 and especially with WSAD. So I tried to find out why as my first foray into the WSAD Profiler. It led me to a method in AcceleratorRegistry that gives me pause: private boolean dependsOn(IPluginRegistry registry,IPluginDescriptor descriptor0, IPluginDescriptor descriptor1) { IPluginPrerequisite[] prerequisites= descriptor0.getPluginPrerequisites(); for (int i= 0; i < prerequisites.length; i++) { IPluginPrerequisite prerequisite= prerequisites[i]; String id= prerequisite.getUniqueIdentifier (); IPluginDescriptor descriptor= registry.getPluginDescriptor(id); if (descriptor != null && (descriptor.equals (descriptor1) || dependsOn(registry,descriptor, descriptor1))) return true; } return false; } This method is recursive, and it is walking the plug-in prerequisites. Opening a perspective (in this case the CVS Repository Exploring) yielded 189K calls to the above method, and the switch while under the profiler took over 45 seconds. I commented out this code and returned false, assuming that the worse thing that would happen is that some accelerators wouldn't work. That reduced the number of invocations of dependsOn to 84 and the switch took six seconds, again under the profiler. This test was on Eclipse 2.0.2. I see that this class is no longer in 2.1, but several copies of this method are still there (search on getPluginPrerequisites). If this is really necessary, perhaps IPluginDescriptor shouid implement a "getAllPluginPrerequisites" or "dependsOn (IPluginDescriptor)" method that saves the result as a set to speed up subsequent invocations.
AcceleratorRegistry is gone in 2.1, replaced by the new key bindings story. This pattern no longer occurs in Platform UI (no senders of getPluginPrerequisites()). Here are the remaining refs I found: org.eclipse.help.internal.appserver.PluginClassLoaderWrapper.getPrereqClasspath (IPluginDescriptor) org.eclipse.help.ui.internal.browser.win32.IEBrowserAdapter.addRequiredPluginID s(String, Collection) org.eclipse.jdt.internal.ui.text.java.hover.JavaEditorTextHoverDescriptor.depen dsOn(IPluginDescriptor, IPluginDescriptor) org.eclipse.pde.internal.runtime.registry.RegistryBrowserContentProvider.getFol derChildren(IPluginDescriptor, int) org.eclipse.ui.texteditor.AbstractTextEditor.ConfigurationElementComparator.dep endsOn(IPluginDescriptor, IPluginDescriptor) The ones in AbstractTextEditor and JavaEditorTextHoverDescriptor would likely be the most sensitive ones, so I'm moving this to Platform-Text. cc'ing Dorian and Dejan for the refs in Help and PDE.
The calls in help do not have any problems: org.eclipse.help.internal.appserver.PluginClassLoaderWrapper.getPrereqClasspath (IPluginDescriptor) should not be called because we use pre-complied JSP's. In self-hosting or other scenarios in which users disable precompiled JSP then the code gets called, but the pre-req chain is small. org.eclipse.help.ui.internal.browser.win32.IEBrowserAdapter.addRequiredPluginID s(String, Collection) is only called once, and then the result is cached (we noticed some performance problems and fixed for M4).
This has been fixed some time ago in the 3.0 stream.