Summary: | Save (Build / Compile?) performance | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jörg von Frantzius <jfrantzius> | ||||||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||||||
Status: | RESOLVED WORKSFORME | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | P3 | CC: | john.arthorne | ||||||||||
Version: | 2.0 | ||||||||||||
Target Milestone: | 2.1 M1 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows 2000 | ||||||||||||
Whiteboard: | |||||||||||||
Attachments: |
|
Description
Jörg von Frantzius
2002-06-27 05:41:00 EDT
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. |