How to determine what is making Eclipse slow?

I'll make a few suggestions - these are in order of easiness. If you are hell bent on figuring out what plugin it was and either joining that project to fix it or send hate mail to a support list, then you probably want to skip to "Profile It" below.

Check the console

If you start eclipse from the command line ( ie type eclipse ) then if there are any exceptions being thrown you'll see them in here. Sometimes slowness can be caused by a plugin repeatedly failing and throwing lots of exception. Sometimes it is something you can fix - sometimes you have to remove that plugin.

Boost your RAM

We love GC but it causes a slow death. The beauty of GC is that your program never runs out of memory - because the user thinks it has locked up and kills it before it actually runs out of ram. So, try increasing the PermGen and other Eclipse memory settings: http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F

Create a new Workspace

I often give up and just delete/recreate the whole workspace. There are so many plugins there is can be a real challenge to debug and often it garbage in the workspace directory that keeps things breaking.

Keep Eclipse Lean

If I want to keep Eclipse really snappy, I'll create an install for a single project and add only the plugins needed. If you can start from the non-EE version you're already far less bloated.

Profile It

The VisualVM that is included in with the Sun JDK (you probably already have it installed.) can be used to see what classes are consuming the most processor time and which objects are taking up memory (and what created them).

Start VisualVM up, and you should see Eclipse listed in the Applications. Right click on the Eclipse entry and "Open" Eclipse inside VisualVM. You can now attach a profiler and see what classes are being used.

Profiling will slow everything down (a lot!) so you might want to start with the smallest possible example you can - or be extremely patient. Especially at the start of profiling it will take a long time as it 'instruments' the classes (injecting bytecode to allow profiling).

One way to know what Eclipse is doing by enabling debugging. There is some information here about debugging eclipse builders, however the process is generic i.e. you need to start eclipse from command line $eclipsec –debug > log.txt and enable debugging for certain plugins using the .options file. I guess you would want to look a bit closely at 'update' and 'build' operations.

Another option would be to use a tool, e.g. MAT (Memory Analyzer), YourKit. I find YourKit to be quite useful, you could for example enable CPU profiling in YourKit and then perform an action in Eclipse which you feel is taking a lot of time. Once the action completes, you can take a snapshot and do some analysis in YourKit. A caveat is that a attaching the YourKit profiler to Eclipse will further slow down Eclipse.

Having said that 150+ projects in one workspace is a bit much. If it is possible you should probably setup one workspace per component with the rest of the plugins in a target platform. All your workspaces can share a single target platform. With 150+ projects a full workspace build alone can take quite a bit of time since a large number of class files have to be generated which means a large amount of disk IO, and eclipse cannot help you there only a SSD can :)