Community
Participate
Working Groups
My eclipse environment (3.1M6) frequently hangs for large amounts of time between operations. This makes it pretty annoying to work with since I seem to be able to type faster than eclipse can respond. When I ran with -debug and displayed the Performance view, I consistently see org.eclipse.jdt.internal.core.DeltaProcessingState taking large amounts of time. My machine is a Windows XP box with dual CPU Xeon with 1GB RAM so I'd expect less of these pauses. Also eclipse is definitely not coming close to maxing out the CPU (as shown with Windows Task Manager). I've tried with different versions of JDK 1.4.2 and 1.5.0 and different vm options (eg -server, -Xmx/-Xms combinations, gc options, etc). Nothing seems to help. So it seems to me like there's something internal that's causing the problems (lots of exceptions? deadlocks?) I'd be happy to try any suggested fixes and report back.
Please provide steps to recreate, as well as full dump to better analyze. The delta processor is converted resource deltas into Java element deltas, and broadcasting. So the time spent may just be in some 3rd party listener of the Java model.
Creating a new package is one of the things that seems to take a lot of time. But this is not consistent. Often there is a big delay, but sometimes this is not the case. I am a user of eclipse and not a developer, how can I get at the full dump that you'd like to see? Thanks.
David - pls explain how to enable traces, VM dumps or using the new instrumentation you just released.
Could you attach the 'performance.log' file ? This file contain data which are display in the performance view. You can find it in the .metadata directory of you workspace. To obtain a VM dump, launch eclipse inside a console. When eclipse seems to be slow or freeze, do 'ctrl' + 'Break' inside this console. To enable trace you must add some entries inside .options file and launch eclipse inside a console with -consoleLog and -debug options. The .options file is in your Eclipse install directory. Add the following entries inside .options to enable jdtcore performance trace. org.eclipse.core.runtime/perf=true # Reports the time to perform code completion. org.eclipse.jdt.core/perf/completion=300 # Reports the time to perform code selection. org.eclipse.jdt.core/perf/selection=300 # Reports the time to process a java element delta. org.eclipse.jdt.core/perf/javadeltalistener=200 # Reports the time to perform an initialization of a classpath variable. org.eclipse.jdt.core/perf/variableinitializer=5000 # Reports the time to perform an initialization of a classpath container. org.eclipse.jdt.core/perf/containerinitializer=5000 # Reports the time to perform a reconcile operation. org.eclipse.jdt.core/perf/reconcile=1000 These options are not available in 3.1M6 but will available be in the next integration build
Hi David, I did some investigation on my end and it seemed like performance was especially bad due to the JDK and eclipse being on a very slow remote drive. I've since moved things over to my local C: drive which seemed to improve things tremendously to the point that I think that was the main cause of the problems I was seeing. I'm not sure if anything can be done for performance when the remote drive is so slow, but at least for me I consider my performance issues to be resolved. If I have any issues when 3.1M7 comes out, I will diagnose using the instructions below.
Close as invalid because the problem seems to be caused by a very slow remote drive. The new .options are available in all integration build >= I20050419-1200 If you notice similar slowness with a not so slow drive, do not hesitate to reopen this bug.
