Reputation: 20301
I am using eclipse 3.5 (cocoa build) on Macos 10.5 with Java 1.5.0.19.
I just have 3 java files opened 1 files ~ 2000 lines the other 2 are ~ 700 lines.
But when I switch from 1 file tab to another, eclipse takes a long time (~ 20 seconds) to switch to another tab.
I have already change the eclipse.ini to
more eclipse.ini
-startup
../../../plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090519
-product
org.eclipse.epp.package.jee.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=512m
-Xms128m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
Is there any way to make eclipse 3.5 more speedy?
Thank you.
Upvotes: 41
Views: 16302
Reputation: 645
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;
[...]
Upvotes: 0
Reputation: 416
TL;DR for the bug thread:
http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution
Worked for me.
Upvotes: 0
Reputation: 545
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:
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.
Upvotes: 0
Reputation: 22731
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.)
Upvotes: 2
Reputation: 41
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.
Upvotes: 2
Reputation: 1063
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
---- 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
Upvotes: 1
Reputation: 22731
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.
Upvotes: 1
Reputation: 38163
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.
Upvotes: 0
Reputation: 203
switching to 1.6 really helps. This is the link to locate eclipse.ini file for mac http://wiki.eclipse.org/Eclipse.ini
Upvotes: 1
Reputation: 38163
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.
Upvotes: 0
Reputation: 11
This might be the bug that was referred to. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229
Upvotes: 1
Reputation: 552
I switched this line in the eclipse.ini file (found inside the eclipse application package):
-Dosgi.requiredJavaVersion=1.5
to
-Dosgi.requiredJavaVersion=1.6
and tab switching was speedy again.
Upvotes: 52
Reputation: 9825
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.
Upvotes: 3
Reputation: 26910
This is an known issue. Since you are using JDK1.5, you can try the Carbon variant.
Upvotes: 0