Speeding Up Eclipse

Thursday, December 18, 2008

Slooooooooooooow

So your Eclipse is sluggish, and you've tried the usual suspects: increase the heap and permgen, run -clean, close projects. You've found all the places where Aptana strangles your install and tried, to the degree possible, to tame its virus-like behavior. But something still feels off. Maybe startup is slow. Maybe, as happened to me, shutdown takes minutes. In my case, my eclipse install got to the point where shutdown was taking 2-3 minutes, and this is on a fairly performant machine. Finally, I had a Popeye moment: "That's all I can stands, I can't stands no more!". I opened up sysinternals excellent Process Monitor utility and watched what was happening. Bottom line: on shutdown eclipse was touching a gazillion different directories in my workspace, even directories on projects that were supposed to be closed. I do not know what it was doing (I suspect Mylyn, though, for what it's worth. But you'd have to rip Mylyn out of my cold, dead hands before I gave it up). So I decided to finally bite the bullet and adopt a practice suggested by many other people over the years (my buddy Mike used to yap at me all the time about this). It's a practice, however, that I tried before but couldn't commit to.

Separate Workspaces

What solved my problems: Separate workspaces. I know, you're thinking, "uh, duh, dumbass. that's what workspaces are for". But hear me out. When you start out with eclipse, you might have 5 or 10 projects in your workspace. A handful of java projects, some CF, some other play-around stuff... whatever. You wanna mess around with AIR, so you have some AIR projects. You have a handful of Flex projects. You decide one day to monkey with CFEclipse b/c you're so keen on giving back to the community, so you check out the 6 or so projects from SVN. You create a couple eclipse plugins yourself. Soon enough, you end up with 50 projects in your workspace. But you keep most of them closed, so technically they should be closed, right? "Yer dead to me", right? Apparently not. So I got my act together and finally separated out my different types of work into different workspaces, and the difference is dramatic. My primary workspace -- whittled down to a mere 31 projects -- starts up and shuts down in seconds. All the other workspaces, ranging from maybe 6 projects to 20 projects, load just as quickly. Nice thing is that now that I've got projects separated out, I don't need to keep projects closed all the time -- at least, not the ones in my "secondary" workspaces.

How to move projects from one workspace to another

But this post isn't just about my dummy AHA! moment. It's about a tip for a really fast way to move projects out of one workspace and into another. Here's what to do: To create a new workspace: Simply go to File -- Switch Workspaces and then type in a new Location. For example, for a workspace containing my Flex stuff, I just typed in c:\documents.....\mesher\EclipseWorkspaces\MyFlexWorkspace. Eclipse will then create a new, empty workspace. To get some of your existing projects into the new workspace:

  1. File -- Import
  2. General -- Existing Projects into Workspace
  3. Click "next"

Here's where it might get a bit tricky, so I'm going to go into all the detail for my own personal setup. I have projects scattered throughout my system, but largely they fall into two places: 1) my webroot where I keep all my cf projects, and 2) my actual workspace, where I keep most of my java projects. I'll start with my CF projects. Let's say I have 50 different projects underneath my webroot, and I wanted to break them into roughly a third. In the "Select Root Directory" dialog that comes up, I went to c:\inetpub\wwwroot. This brought up a ton of projects, only a third of which I wanted to move into my new workspace. It then scans for all projects and loads them into the window at the bottom of the panel. I clicked "deselect all", then selected just the projects I wanted to import. Then, I clicked Finish. That brought all the projects I wanted to import into my new workspace. NOTE: I did NOT click to "copy projects into workspace!". I repeated that step for the other projects I wanted to move into separate workspaces. Finally, I went into my primary workspace selected the projects that I had moved into separate workspaces, and deleted them. I did not select "remove from file system"! Remember... by moving projects to another workspace, you're not physically moving the location on the file system.

Preferences

One thing to note when creating new workspaces is that each workspace gets its own separate Preferences. This is a good thing! But it does create a bit of extra work if you simply want to replicate your preferences among the various workspaces. For me, the quickest way to move my preferences from the primary workspace from the secondary workspaces was this:

  1. in primary workspace, go to File -- Export
  2. filter on "preferences"
  3. Export all preferences to a file somewhere... I put mine on my desktop
Then, switch to another workspace.
  1. in this secondary workspace, go to File -- Import
  2. Filter on "preferences"
  3. Navigate to the file you created
  4. Click Finish
That's it! Do that for the other workspaces, and now your preferences are consistent. Got any other tips for speeding up Eclipse?

9 comments:

Bradley Moore said...

Ooo, I am definitely going to give this a try. Thanks.

Jake Munson said...

My jaw dropped when I read how many projects you have! I work in a large corporation on a team that manages most of the company's internal/external web sites/applicatins, but I only have 21 projects. You must be a busy contractor or something...

JLChoike said...

Here are my vmargs, which I have found to be more than sufficient:

-vm
C:\dev-wks\java\jdk1.5.0_13\bin
-vmargs
-Xms768m
-Xmx768m
-XX:PermSize=256m
-XX:MaxPermSize=256m
-XX:+UseParallelGC

I am running a Dell D630 with 4GB RAM and a Core 2 Duo. The matching min/max values for heap and perm size prevent Eclipse from wasting resources to grow the memory allocation.

billy said...

Thanks, Marc. Others here and myself have commented how we needed this! Hey, Mike Henke just published a similar article in this month's FusionAuthority, "Turbo Charging Eclipse" - very detailed and, likewise, some excellent info.

bill

Mike Henke said...

Thanks Bill for the mention. Yeah, I covered "Runtime Spy" for checking plugin startups and then something like I blogged about before using some Sun JVM commands in the the eclipse.ini file to get the xms and xmx values for your computer.

Marc Esher said...

@Jake Nope, not a contractor. This is all in the service of workin' for the man. I just seem to get my hands into a lot of different pots. One thing I do though is that when I download a project, like coldbox, coldspring, etc, I usually set up an eclipse project for it so that I can easily poke around and see what's going on under the hood. Even something as small as poicfc I'd do that for. So I have a dozen or so of those types of projects.

The rest are either "real" work projects or sample/play/practice types of projects. I'm a pretty ardent practitioner of "play" programming, where I'll just poke around trying this and that. and a lot of the time, I'd prefer to do that in separate projects rather than as subdirectories of a larger "sandbox" project. I do have a pretty large sandbox, but I reserve that for one-off type stuff.

@JLChoike... for me, runtime performance has never been an issue, because I run eclipse with loads of memory. It's just lately been about startup and shutdown. and I'm really starting to suspect that a single plugin, possibly 2, is doing something on shutdown that I don't know about. Mylyn just "feels" like the culprit at the moment.

@bill and @mike, I look forward to getting the latest copy of FAQU... it hasn't hit our mail yet.

Wesley said...

Marc, Mylyn should not have any noticeable impact on your performance. In fact, Mylyn should improve performance by reducing the number of open editors, which consume a lot of memory.

If you are able to investigate and find out that this is related to Mylyn, this would be considered a major bug and I'd encourage you to report it:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Mylyn

Marc Esher said...

Wesley, thanks for your comments. The reason I haven't explored this any more with mylyn is that I find it virtually impossible to figure out exactly what is really going on during shutdown without selectively disabling and enabling plugins, and I'm not up for that.

There are two things leading to my hunch: 1) when i did a fresh install of eclipse a month or so back, shutdown was fast until I hooked up mylyn to our jira repository. it "seemed" to me that after I did that, shutdown started taking a long time. 2) I get suspicious of plugins when they start hiding options or doing things behind my back that I can't control. I remember back in the day, in preferences, mylyn used to have easy-to-find preference pages for controlling the whole data usage/backup thing. I don't see that anymore. however, if I watch process monitor, I can see that mylyn's trying to zip a backup file. it's been trying for over 15 minutes now, and I don't know how to turn it off. This feels downright aptana-ish to me (aptana showing various virus-like behaviors to me, no matter how sweet a set of plugins it may be).

I know it's not much to go on, but it's all I have right now. And definitely not enough to clearly identify it as the culprit.

the other thing is that now that I've separated out my workspaces, shutdown takes hardly any time at all, so I can't just disable mylyn and rule it out as the problem. Believe me, I'd love to... mylyn has literally changed the way I work for the better.

so while i generally don't like to publicly talk shit on excellent projects, maybe I'm hoping that someone will read this and say "no, stupid, you're wrong.... here's what's going on during eclipse shutdown".

I'll try to find some time to poke around with this and see if I can get a more definitive answer. Thanks for prodding!

Wesley said...

Marc, thanks for the additional details.

The preference pages to configure Mylyn options are still there, but the parent node is now called "Tasks" instead of "Mylyn".

Mylyn does zip context files, but these files are tiny and should zip instantly. I don't think a problem with this has ever been reported, so it would be great if you can reproduce this and file a bug with a screenshot.

It's great to hear that Mylyn has changed the way you work for the better!