Question

We have in one of our applications a single eclipse project that contains all the code. I think it is a fair amount of code – not a small project, but not a huge one either. I ran a small check on it and got:

Found <4245> code files
Totaling <421557> lines of code

This check includes any code lines that are not empty or just containing { or }.

So it is not a huge project – however, the .project defines many links to mask the real directory structure to create a different view for the Package Explorer – so the project will make more sense.

The problem is that eclipse is working very slow in some areas.
Examples:

• Find references in workspace (Ctrl+Shift+G) – Takes a very long time compared to previous projects I worked on in this magnitude
• Decompilation via jadclipse or JDEclipse can take as much as 1 minute – causing eclipse to show the lovely (Not Responding) suffix on the title-bar. Same code decompiled from outside of eclipse takes less than a second.
• JUnit test execution – the initiation of the execution takes over 10 seconds, in which eclipse doesn’t seem to do anything important.

Any ideas why this could happen and if it can be a result of a “complex” project structure?

Using eclipse 3.6, without many plug-ins installed.

EDIT:

Using resmon eventually showed me the problem. I noticed that eclipse keeps trying to connect to a network share – it didn’t take much CPU or IO, but still it was there.
When inspecting the .classpath file I noticed this:

<classpathentry kind="lib" path="build_class" sourcepath="some share using samba ..."> 

The share we were referencing wasn’t even a correct path, but that probably caused a lot of overhead in every activity.

Removing the sourcepath attachment and leaving it as:

<classpathentry kind="lib" path="build_class"> 

Solved the problem immediately. Since we were using a decompiler plug-in any way, we were not harmed by this change.

Answer 1

This is typical of a situation with one or more resource bottlenecks.

You will need to investigate with operating system tools what Eclipse is waiting for (Task Manager, and perfmon are great for Windows), and if that doesn’t help investigate Eclipse itself with jvisualvm in the Oracle 6 JDK.

You will most likely find that the system is waiting for the underlying harddisk. This can have several reasons, some being:

• Eclipse is a big program. The operating system may need to swap parts of it out to disk. For Eclipse this ruins performance. Really!
• Eclipse needs a lot of disk access. If you have a slow disk or (horrors of horrors) an overly aggressive anti-virus program, this also ruins performance. If the operating system has plenty of spare RAM it can cache files in memory giving better performance.

If this is the case, get more RAM.

If the underlying system is fine, but Eclipse on its own is very slow (but other Java programs run fine), then see with jvisualvm how memory usage is behaving over time, and if you have many, frequent garbage collections when you need to wait, you may need to allocate more memory to the JVM. This is done in the eclipse.ini file.