Community
Participate
Working Groups
I2003-02-14 I have a project that is referenced by many other projects (like org.eclipse.resource). If I make changes to a class within this project and save them, it takes quite a (annoying) long time for Eclipse to compile this class. The class itself is only used within the project itself. Metrics: Saving sourcecode in the specific project results in a lot of "Reading resource change information" message. The whole process takes 11seconds on a 1,7GHz P3. Eclipse is started with -Xmx256M, so it's not GC issue (the process has taken only half on the memory). There is no output in the log file.
You may want to enable the Java builder trace to indicate which types got recompiled, and why it thought it needed to. Add the following to your .options file (next to eclipse executable): org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/builder=true
Doesn't reveal anything useful (imho). A lot of : Starting build of <project> @ Thu Mar 06 13:36:40 CET 2003 About to read state... Successfully read state for <project> Nothing to build since deltas were empty Finished build of <project> @ Thu Mar 06 13:36:41 CET 2003 However, the timestamps indicate that everything took more than 10s. No entry takes especially long. Aynthing more I can do?
Yes please run your test twice. The first pass needs to read build states and will take some time (if your workspace is large). The trace from the second pass will show which types/files need to be rebuilt.
Same result. Detected one change in first run and one in second run. On first run, the build states were loaded. First run took 12s, second run (without loading of state) took 10s. There were 48 projects that directly depended on the project that was changed. However, the class is not referenced in any of those.
From the trace, where is the 10 seconds? Can you add the trace as an attachment? How large is the source file?
Source file has less than 1000 lines, the ten seconds seem to be equally spend on all the dependend projects. That said, 10 seconds for 48 dependent projects means 200ms per project. That doesn't sound too bad...
Actually 200 ms per project when they have nothing to compile is fairly bad. Is your workspace stored on a network drive? Or is your jdk install stored on a network drive?
Nope. Both are stored on local NTFS volumes. Workspace is stored outside of the Eclipse installation directory (-data), virus scanner is not active (not even running).
What's the TaskManager tell you... is your machine maxed out for the entire 10 seconds? How's the memory consumption? Anything else running on your machine?
To give you some idea of our 'normal' performance, I have a workspace with all of the Eclipse drop from source. That's over 60 projects. A simple change to a source file in the core.resources plugin (numerous dependent projects) takes less than 2 seconds.
Making some investigations (filemon) revealed that Eclipse is touching a lot of JAR files within the JDK directory. That brought into my mind that I have set JDK 1.4.1_02 as default JDK within Eclipse, resulting in 9 files (27MB) within its system library path. I cross checked with JDK 1.3.1_07 (3 files, 17MB) and compiling took .... about 1-2 seconds. Also verified that after switching back to JDK 1.4.1 it still takes 10 seconds. JDK 1.3.1_07 ....... 1-2s JDK 1.4.1_02 ....... 10s (timings taken from the debug output)
Submitted fix for consideration in the RC3 build. While initializing the classpath for each project, we were recomputing classpath error markers for referenced projects instead of relying on the fact that error markers were already computed for their classpath.
Good find. This code should never create markers, it is only supposed to get output contributions from a prereq project. One more thing, I think it should be: IClasspathEntry[] prereqClasspathEntries = prereqJavaProject.getRawClasspath(); Indeed, outputs are never exported across projects (they belong to each project) thus no need for an expanded classpath. Next, no source folder can be specified through variables/containers, thus a source folder can only occur inside a raw classpath (we do similar assumption in JavaModel already).
Kent - please double check the version I just released.
Looks good.
Verified.
