[Solved]-Eclipse 3.5 (and newer) switching tab is very slow-eclipse

This is an known issue. Since you are using JDK1.5, you can try the Carbon variant.

I experience the same issue using OS X 10.5.7 and Eclipse 3.5.2 on a fairly low end machine (early 2006 iMac with 1.5GB). Right after I start my machine however, everything is really snappy. I can even launch JBoss AS and there is still no slow-down. I monitor "Swap used" in activity monitor, and it stays at 0 bytes swap used.

Then, I launch something else, like iTunes and mail or switching to another account.

Things become slow then, which is expected, and I see "Swap used" increasing. Eclipse slows down to a crawl, and working with it is near to impossible.

Then I logout the other account, close down all other apps that I opened, so the state of my machine is basically the same again as when it was still fast. BUT... it stays dog slow! Even though I closed all the other apps, "Swap used" in activity monitor only decreases a little (from ~1.2GB to ~700MB). Just switching tabs between 2 very simple Java files takes up to 20 seconds, meanwhile I see in activity monitor that the CPU usage goes up to a solid 100%.

There definitely is something strange going on here. This does not seem like normal behavior. It is as-if Mac OS X goes into a 'slow mode' when I demand too much resources from it, but when the resources are there again it fails to recover.

Highly annoying!

If I reset the machine and open the exact same working set again (Eclipse with the same 2 files open, JBoss AS started in debug mode, Safari with 1 window) everything is really fast again.

I can now more or less confirm that the problem is really with Eclipse 3.5.

I've run Eclipse on a much more powerful Mac, a 27" core I7, 2.93Ghz with 8GB ram and a SSD running OS X 10.6.4. Initially this was extremely smooth and snappy, but after an up time of a dozen hours or so, Eclipse suddenly began to slow-down again. I had very little to almost nothing running in the background. Just Eclipse (32 bits, given it 1.5GB memory), JBoss AS and Safari.

A simple tab switch would take a few seconds and meanwhile I noticed the CPU load on one core going to 100%. The same happened with switching perspectives and various other operations.

When I restarted only Eclipse, everything was completely fast again. This happened a couple of times.

For me the issue was the SVNKit connection integration to the Juno version of Eclipse. I am doing Android Development using the Juno version of Eclipse and when I turned on the SVNKit Team Integration I got the following issues described:

1. Very slow switching between code files in the Eclipse IDE.
2. Extra large gap and space in the tool bar between the print and Android SDK Manager icons.

For me... I turned off the following settings under Window->Preferences->Team->SVN under the View Settings... there was a setting for "Show synchronize info incrementally"... I turned that off and the switching between files improved.... but there is still a delay versus NOT having SVN connected.

Without SVN connected... the switching between files is normal.

I had Java 1.6 in the Eclipse.ini I did not change the settings for memory.

TL;DR for the bug thread:

http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution

Worked for me.

The original problem of slow switching between tabs has reappeared in Eclipse Neon (4.6.2 only?) using the Dark theme.

Solution: disable themed scrollbars in e4-dark_win.css (bottom of file): StyledText { swt-scrollbar-themed: false; [...]

This might be the bug that was referred to. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229

switching to 1.6 really helps. This is the link to locate eclipse.ini file for mac http://wiki.eclipse.org/Eclipse.ini

This eclipse bug report is spot-on with the behavior you describe. (I had the same experience using a new Juno installation on a beefy XP machine.)

https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272

The most useful part of the bug report was in comment 29, which suggests creating a new workspace. The easiest way to do this is:

1) exit eclipse

2) rename .../path/to/workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi (e.g., append ".old")

3) start eclipse

I believe changing -Dosgi.requiredJavaVersion=1.5 to 1.6 may help only incidentally, if at all.

Increase the memory limits in eclipse.ini seems to have fixed this for me - not sure if it will stay fixed though

FROM:

-vmargs
-Xms40m
-Xmx512m

TO

-vmargs
-XX:MaxPermSize=512m
-Xms256m
-Xmx784m

ALSO - if you came from aptana3 and imported your project - You need to do this

1. Click Project Properties
2. Go to "Builders"
3. Make sure there are no "Missing Builders" If there are, uncheck them - I had two left over from aptana when I imported my project (com.aptana.ide.core.unifiedBuilder AND com.aptana.editor.php.aptanaPhpBuilder)

---- UPDATE ----

It was fixed - but not for the reasons I thought. My SVN was no longer recognized by eclipse. As soon as I hit 'share with team' and reconnected it the tab-switching issues reappeared. I'm going to try and figure out if It's an svnKit vs JavaHL problem - I'm not sure which connector I picked when I setup eclipse this time.

If you want confirm this is your issue trying disconnecting from the SVN (Team->disconnect) and restarting eclipse

I know this is kind of late to the game, but I found that changing the permissions to ~workspace.metadata.plugins\org.eclipse.e4.workbench to deny myself access stopped the slow-down issue.

Seems that Eclipse (4.2.0) writes out a corrupt settings file every so often, and when it's loaded in at startup again it slows everything down as it's constantly throwing errors internally. Changing the security on that directory so that Eclipse can't write to it is a kind of "fix"! It does mean that each time Eclipse is started it's back to its default settings, but if speed is more important, I think it's a worthwhile sacrifice.

There are now patches for Juno to begin addressing this issue. See comment #212 on bug 385272 for information on how to update your installation. If you wait a little longer you should find these fixes in the Kepler milestone on 12/21/2012.

(I believe the other suggestions posted here, e.g. increasing memory or tweeking various startup params or prefs might have some positive effect on performance, but the underlying problem is threads run amok as described in the bug report.)

Go with the 32-bit Cocoa release. The 64-bit won't help IMHO. It really works great on my 2.4 GHz MBP. I usually have about 30 files open, some fairly large, never experienced what you describe.

Try to get a new plain-vanilla 32-bit Cocoa distro, don't modify anything and check if there's an issue. It could be a rogue plugin, too. Do you have any installed?

Check you heap status. Open the Eclipse preferences, in the very first preferences page there's a "show heap status" option. You might be running low on memory. Check the swap status of your machine using the activity monitor - if it swaps a lot I'd recommend shutting down other applications. In general, I recommend 4 GB RAM for development machines.