Community
Participate
Working Groups
Build id ? From snapshots taken by Scott Rich, it looks like JDT Core is doing too much work on startup.
Created attachment 17816 [details] Snaphots taken during RSA startup
Comments from Nick Edgar: From a quick glance through these, I can see a couple of problems: - JDT core is doing work on startup (call to JavaModelManager.loadVariablesAndContainers). Can this be deferred until needed? I believe you need to be careful about circularities on startup as well (e.g. JDT core startup -> classpath computation -> PDE container -> back to JDT?). OSGi can timeout in this scenario too. - PDE container queries do parsing, which is expensive. Can it leverage the existing plug-in registry picture in core? I know it can't in general, since the PDE target may not be the same as the host, but in the case where it is, can this be optimized? Talk to Wassim. Another thing we'd like to investigate is bringing up the workbench before restoring perspecives/views/editors, even if it it has to bring up a progress dialog while doing so. This won't be any faster, but will appear more responsive, and will be more entertaining for the user ;-). Unfortunately, the UI team has no cycles to play around with this right now. Nick
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.
Changed JavaCore#setClasspathContainer(...) to optimize the startup case: if the container's classpath entries are the same as the classpath entries recorded on the previous session shutdown, then it doesn't go through another SetClasspathOperation, but simply record the new container.
On a monster workspace (more than 1000 plugins), the startup time went from 58 seconds to 26 seconds.
Optimized setClasspathVariables(...) the same way.
Verified for 3.1 M7 using build I20050513-0010.
