Community
Participate
Working Groups
Build: I20030206 (2.1 M5) The plugin import operation (defined in PluginImportWizard.getImportOperation), runs two separate workspace runnables. This means there is a notification phase in the middle of the import (you can see the navigator update if it's in the background). This kicks off activity in the java indexing thread, and so the remainder of the operation takes much longer because it is fighting for CPU and various locks with the JDT indexing thread. When profiling, I noticed that typical core API calls from within the first operation (PluginImportOperation), were much faster than calls from within the update classpath operation, due to the differing CPU contention. Wrapping this entire process in a single workspace runnable would make this more efficient, and should speed up the import. You can use the convenience class WorkspaceModifyDelegatingOperation to wrap your current IRunnableWithProgress into a workspace operation.
Incidentally, the profiler also showed about 12% of import time was in WorkspaceModelManager.validate. It is validating that all plugin projects still exist for every dependency that gets added (results in > 1000 validations when importing 15 plugins). I recall this was added to workaround a bug in the resource deltas (bug 11956), which has been fixed. Perhaps this can now be removed? (Side note: Jeff asked me to sniff around for performance problems, but feel free to defer until after 2.1 if you're not comfortable making changes this late).
Import operation is indeed separate from classpath computation. We want the Java model to do its work between the two because we want classpath computation to see the new situation in the workspace. Our classpath routines are adaptive i.e. they produce different results depending on whether a certain plug-in is represented as a java project in the workspace or as an external plug-in in the target platform. For this to work, Java model must digest the new projects that have just been imported, and that will not happen unless it receives resource change notification. We feel more comfortable with validation, but we can see if we can temporary turn the validation off when we know we will access the manager many times in the loop. Wassim, investigate if we can add 'setValidationEnabled(boolean)' on the workspace model manager and use it to validate at the beginning of an operation in which the manager will be accessed many times but no data will be changed to warrant re-validation.
The import operation needs to be a two-step process for accurate classpath computation. The only problem that needs to be addressed is the excessive validation. Too risky to do it now. Defer to 2.2
Reopening to address the inefficiency in Workspace model manager. Workspace model manager is certainly doing a lot of unnecessary work, and will be addressed as part of the whole model revamping currently being done. As for the double import operations, it will be addressed as part of the solution of bug 48368
Fixed.
