Link Details

Only two tips are really "optimization" in the traditional sense; the rest are just trivial functionality tweaks.

You're right newton_dave. That's what I meant with 'comfort'.

I voted this up, but the automatic workspace refresh can be a performance killer for larger workspaces. Maybe Eclipse has optimized the refresh in 3.5, but in 3.4 and earlier it could be a problem. I think it's a dubious suggestion.

This is an interesting hint, joecoder. One of my current projects is something like 30 java projects with ~5000 class files. I've seen no performance issues so far while auto refresh is active. Workstation is WinXP, Intel Duo Core 3.x GHZ, 4 GB RAM.

I don't remember how many projects were in the workspaces I referenced, but there were definitely more than 30 projects; probably 50-70+ projects and I'd guess several 10's of thousands of files. Java class files are not the only resource being monitored. Other resources could be configuration files, data files and so on. Also, it's not a continuous slow down. IIRC, it happens on specific IDE operations and Eclipse either appears to hang or is relatively unresponsive. I assume some operations like refactoring and cross-reference searches are aggressive about checking whether the workspace should be refreshed.

"Reply" link, folks :p

70+ projects in one workspace? Ew.

Hi joecoder. 50-70 projects is huge. We tend to only check out crucial projects into the workspace.
We use a Maven2 project repository so you only have to check out those projects you are really working on. The other projects will automatically be downloaded from the repo as jars.
On another project we're using Eclipse Bundles to manage dependencies. We use the target plattform feature so only crucial projects are checked out into the workspace. Barely changed projects are included into the target plattform in form of Eclipse bundles packed as jars.

This reduces the current number of files in workspace alot.

I'd need to know more details to know if that would have worked for us. A combination of merciless refactoring and collective code ownership (people didn't stay focussed in specific code silos/projects for very long) might have had some impact on the approach you describe. It sounds we would have needed to create or modify workspaces frequently. Also, in my experience, teams that use Maven for day-to-day code management with Eclipse have been a PITA. I know, I know. Some people love Maven. Some people also like to surgically implant metal spikes in their head or eat broken glass, but ... ;-)

Eclipse handles the large workspaces well when configured properly. We weren't modifying files outside of Eclipse very often so that may be another difference. If Maven is constantly modifying files outside of Eclipse, you would probably want the automatic workspace refresh.

It wasnt my intend to offend to you. Having large workspaces in Eclipse is fine. There are things to avoid large workspaces as I mentioned above. But thats just a tiny side effect of these tools like Maven or Equinox. :)

The reason why I decided to put this Auto-Refresh tip into my article was that Ive met many people which doesnt like the workspace concept of Eclipse. One reason was this out-of-sync effect. I'm using auto refresh without any performance issues. From time to time I see myself editing or adding files from the file system (e.g. new Icons or other resources).
But Ive heed your advice and edited the article.

wow, from reading this, i realllllly need a new dev pc at my work
im on a 3ghz single core and 2gb mem

The funny part is that our brand new dell workstations all got 8 GB of RAM but are delivered with 32 bit of Windows XP so we can use a maximum of 3.x GB. :/