Summary: | Extremly slow startup | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Philipe Mulet <philippe_mulet> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 2.0 | ||
Target Milestone: | 2.0.2 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Philipe Mulet
2002-09-13 09:22:33 EDT
Wasn't able to reproduce. Need more evidence. Got the same problem today. I took several snapshots of the threads activity and it seems that all the time is spent in getRawClasspath(). Isn't the problem that we don't cache the classpath if the project is not open? This could indeed lead to more work than expected. Now it seems that multiple classpath containers are running inside each other, which I find suspicious (though if querying other project classpath for cycle detection, it will try to find project custom container values). Caching elsewhere would be a good approach (using PerProjectInfo). Fixed by caching raw classpath and lastResolvedClasspath on the PerProjectInfo. Removed caching on the JavaProjectElementInfo. Another thing to consider is that the SetClasspathOperation seems to be naive when it comes to performing a cycle check. It doesn't optimize the case where no project prereq has changed (when computing the delta, it knows this). Alternative is also working great, combined with the operation batching. Still backporting the per-project-info fix into 2.1M1, since it proved to be improving the behavior significantly. Verified Backported to 2.0.2 |