Community
Participate
Working Groups
[build: GM3] When I simply touch a class (insert and remove a space inside a java comment) and save afterwards, the saving takes at least 6 seconds on a 1,6Ghz machine with enough RAM. During the delay, the status line sometimes reads "Reading resource changes for...", sometimes "Invoking builder on...". The problem is reproducible only within my current project. With a fresh workspace and new project it does not occur, with a new project in the same workspace it also doesn't occur. I did not try recreating the project with a fresh workspace. Project size is ~180 classes, i.e. classes available as .java files not within jars. There is only one project in the workspace. OS is Windows 2000. I think the problem occured only since one of the Fx releases. Both eclipse install and workspace reside on a local drive. I'm using CVS. There is one plugin installed, solareclipse.
Jorg, you could provide us with more diagnostic information by doing the following: Copy the file eclipse/plugins/org.eclipse.core.resources_2.0.0/.options into the eclipse/ directory. Edit this file, and set the following flags to true: org.eclipse.core.resources/debug=true org.eclipse.core.resources/build/failure=true org.eclipse.core.resources/build/invoking=true org.eclipse.core.resources/build/delta=true Then restart eclipse, but add the "-debug" command line parameter. Please attach the output that is generated on the java console when you run your test case (add/remove space and compile). Thanks.
Created attachment 1655 [details] debug output
I'm afraid this won't tell you a lot :-( However, I have "Refresh Workspace on startup" turned on, just in case this explains the first build (I'm not too sure on how to interpret the output). Interestingly, the first build seems much quicker than the second?
Jorg, thank you for providing that trace information. The interesting line in the generated output is: Builder finished: JavaBuilder(biogen) time: 7090ms I am guessing this is the time for the build after add/remove space then saving? One more thing you could do... start with those trace options enabled again, but repeat the test case (add/remove space + compile) about five times. I would like to see if the time is consistently high. Usually the first build takes longer because it needs to restore old build state from disk. Classloading and JIT compile times also usually affect the first couple of iterations of a given use case. Thanks again for taking the time to help us track this down.
Created attachment 1672 [details] repeated add/remove space + compile
The second set of results shows that the java builder is consistently taking over six seconds to compile after a no-op change. Moving to JDT Core.
Jorg, can you please run the last test (build 5 times) once more but first add the following 2 lines to the .options file in the eclipse/ directory. org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/builder=true This will give us a break down of what the builder is doing... thanks.
Created attachment 1685 [details] more debug options turned on
By the looks of the trace, it is taking 6 seconds to compile a single file... which would be understandable if the file was very large. Jorg, does it matter which file you try to compile? What are the file sizes of the 'slow' files? If you do a full build then compile a single file, do you still see 6 seconds?
It doesn't matter which file I compile, it always takes that long. The file sizes are quite normal (5-8KB in the average). If by "full build" you mean "Project->Rebuild All", then yes, I still see those 6 seconds.
Ok, my guess is that its taking a very long time to open/read from a jar file (possibly even rt.jar). How many .jar files does the project specify? Are any of the jar files in the project located on a network drive? Can you paste in the .classpath file for the project... that might show us something.
OK, that seems to be it. Most of the .jars were on a network drive, with one of them sized 25MB if that matters. I put them all on a local drive, and now all is nice and snappy again :-) Sorry for the inconvenience and thanks for your help! (Next attachment shows the new build times, which seem quite OK to me, at least in comparison to before;)
Created attachment 1689 [details] problem solved
Closed... some networks can be very slow. Unless you really need to share files, you're better off with everything on your local machine.
