Community
Participate
Working Groups
Build: I20050329 My test case is a workspace with all of the platform-core module checked out from eclipse.org. The workbench is in the Java perspective, with three Java editors open. 18% of the whole startup time in this case occurs in ICompilationUnit#becomeWorkingCopy(), called from the Java editor. Since this method has no return value, would it be possible to run the body of the method in a background thread (indexer thread or a Job)? The bulk of the cost is actually in classpath container initialization... I will attach a profiler trace.
Created attachment 19290 [details] Profiler trace output
The root issue is that no one should request this service during startup, and this is likely a consequence of platform/ui reopening editors during startup. Also 3 editors opening when only one is visible is a known issue in platform/ui as well.
Created attachment 19325 [details] Another profiler trace I don't think the UI issue with opening multiple editors is related here. This second trace is from a startup where only one Java editor was open. In this case the becomeWorkingCopy() takes 21% of startup. It looks like the classpath setup cost is constant regardless of the number of editors that are open. Would it make sense for the Java editor to avoid calling ICompilationUnit#becomeWorkingCopy so early on? Perhaps the editor could do this in the background, if necessary, after the editor is opened?
One editor is expected due to UI deciding to refresh editor on startup, but there are issues in this area, see bug 75558 or bug 85005. As for forking work in background, this is nothing JDT/Core can decide for the editor; and this is an interesting suggestion. Behind working copy reconciliation lies all loading of JDT/Core plus initialization all classpath entries, invoking in turn more plugins (PDE) to initialize their classpath containers. John - my claim about UI reopening editors during startup is that you could construct some workspace without any visible editor, but still UI would recreate it for no good reason (can't find bug anymore).
Moving to JDT/UI for investigating alternate solutions. JDT/Core cannot deny service during startup.
I could imagine (maybe wrong) editor to persist all it wants to re-display on startup (mostly annotations). Likely nothing has changed from the last time it got reconciled anyway.
Moving to JDT/Text to investigate alternative solutions.
Re: comment#4, related bug is bug 83316.
Note that clients can enable that editors are closed on shutdown. Maybe we should enable this per default. We call becomeWorkingCopy(...) with a deactivated requestor. This is what takes time - caching the annotation won't speed up that call. The call is a must to create the underlying buffer and we need to have this correctly created in order to allow the user to type into the editor. We can't put this into the background. >Likely nothing has changed from the last time it >got reconciled anyway. If that's the case, why is JDT Core then spending so much time just to get the working copy? Can we try to make the classpath container initialization faster? It's not just the editor which suffers from this, same can be seen if we startup without any editor being opened but Java Browsing perspective is active (with all views populated upon shutdown): as soon as the views get restored we wait for the class path to be initialized. Moving back to J Core to look whether classpath initialization can be made faster.
The editor startup bug mentioned by Philippe in comment #4 is bug 31621. I haven't actually verified if this bug still occurs.
> Note that clients can enable that editors are closed on shutdown. Actually, this pref has been removed from the IDE as part of the preference page simplification work (it still exists under the covers for RCP apps -- see bug 82476).
Re: comment#9 The Java Model is not persisted across session, and this is what would be required to construct what you are asking for. I am only interested in getting editor contents back, and that I agree requires buffer/model initialization. If no problem is required, maybe we could bypass some of the classpath initialization alltogether, but likely hard to achieve since the model is needing the classpath information to simply figure where the unit is sitting (root/package/type). We need to better understand this very specific usage.
Jerome - when populating the model for a working copy. If problem requestor/AST is turned off, why do we even need to obtain the resolved classpath ? Dani - do you confirm not even needing a DOM AST ? Then next question: how do you reobtain the editor annotations in new session ?
Dani - may I also suggest you enter a PR in your bucket to investigate improvements in your land ? Having us be more lazy is one thing, but having you ask less services is another good one. Forking actual work in background job, or persisting information across session, or both, or more...
Changed JavaModelOperation to initialize roots only if the operation can modify package fragment roots. Only SetClasspathOperation and BatchOperation now declare that they can modify roots.
Changed PackageFragmentRoot#determineKind(IResource) to use the resolved classpath (and not the expanded classpath as it used to do).
Note that determineKind(...) is called when opening the package fragment root of the working copy.
Opening the Java project of the working copy causes all containers to be initialized. Changed JavaModelManager#batchContainerInitialization to default to false so that batch container initialization doesn't occur on startup.
Will these recent fixes be in the I20050419 build? I can do some profiling to re-test my startup case when the fixes are available.
Yes these changes will be in I20040519. But I'm still working on this bug :-)
The parent of a working copy doesn't need to be opened to be able to use the working copy. Changed CompilationUnit#openParent(...) to not open the cu if it is a working copy.
Starting my monster workspace (i.e. a workspace than contains more than a thousand plugins), becomeWorkingCopy() used to take 41s (out of 58s to start this workspace). It now takes 400ms.
Wow, cool.
Verified for 3.1 M7 using build I20050513-0010.
