[performance] PackageFragmentRoot.getRawClasspathEntry() has bad impact on startup performance

[laeubi]

While looking at a problem here I noticed that PackageFragmentRoot.getRawClasspathEntry() has a very bad impact on startup performance because it calls project.getResolvedClasspath()

eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/PackageFragmentRoot.java

Line 616 in 17fc318

project.getResolvedClasspath(); // force the reverse rawEntry cache to be populated

this leads to a resolve operation of all classpath containers (that actually should happen in a background thread!) in the main UI thread whenever one has an open Java Editor + Package Explorer open. This even blocks the whole UI startup of eclipse.

This is sadly not the only place where this could happen... but the other places are more UI related.

[srikanth-sankaran]

Jay, thanks for taking a look

[laeubi]

Especially calling "Raw" ClasspathEntry would indicate for me it is actually not resolved as there is also

eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/PackageFragmentRoot.java

Line 630 in 17fc318

public IClasspathEntry getResolvedClasspathEntry() throws JavaModelException {

[jarthana]

Classpath containers are designed to be lazily initialized, so removing getResolvedClasspath shouldn't make a difference. Anyway, let me run some tests/experiments and get back.

[laeubi]

Classpath containers are designed to be lazily initialized

Can you give an example? I just take a look into subclasses of ClasspathContainerInitializer that I found in JDT+PDE an none of them are lazy all of them sooner or later calling JavaCore.setClasspathContainer in the calling thread of org.eclipse.jdt.core.ClasspathContainerInitializer.initialize(IPath, IJavaProject)

[jarthana]

Classpath containers are designed to be lazily initialized

Can you give an example? I just take a look into subclasses of ClasspathContainerInitializer that I found in JDT+PDE an none of them are lazy all of them sooner or later calling JavaCore.setClasspathContainer in the calling thread of org.eclipse.jdt.core.ClasspathContainerInitializer.initialize(IPath, IJavaProject)

OK, my last statement wasn't accurate. What I had in mind was two things: the resolution of the classpath entries itself. getResolvedClasspath() resolves the classpath on demand and no need for it to be invoked when getRawClasspathEntry, which you have called out already. Second, the initialization of the containers themselves is done in a background thread.

BTW, I just ran all model tests after removing the code in question and didn't observe any difference in behavior. All tests passed and took about the same amount of time.

[laeubi]

Second, the initialization of the containers themselves is done in a background thread.

Only if JDT.UI can start before anyone calls a method that enforce an init of the containers.

[laeubi]

By the way if anyone wants to debug it simply do the following:

1. Put a breakpoint in PackageFragmentRoot#getRawClasspathEntry
2. start a new ide instance and open a java source editor from a project (close any other editors) a
3. restart the ide in debug mode and see the method is hit in the main thread, no UI is displayed until the breakpoint is run