Or Pimp my Eclipse
If you’ve been experiencing horrendous performance of Eclipse on OS X, or maybe you even did not know that Eclipse actually can run very fast, you’d be surprised to learn that apparently it is very easy to make Eclipse run 4-5 times faster on OS X with proper settings to your eclipse.ini file.
Working with Eclipse on OS X felt horrendously slow! I had already noticed this nuance in the past and I thought that the Eclipse is just not meant to fly on Mac's (oh well…), especially when there are so many different distributions for OS X, it signals that the project is in a shifting phase basically (it is shifting from Carbon to Cocoa) and that you should expect all kinds of problems.
I bet many people not having experience with Eclipse on other platforms would think this is normal. It’s Java, so it is supposed to be slow and they just go and hate it and sing how X-Code is great. The thing is, they probably never experienced the full potential of Eclipse – a pity. Hopefully this post can change your mind and help you experience the wonderful world of Eclipse (ok, I am being a little dramatic here). Ok, let’s dive into that.
Since I am pretty heavy user of Eclipse the slowness of Eclipse quickly grew on me and I started looking for ways to try and do something about it.
In the past while experiencing slowness with Eclipse on Windows, I played with the memory allocation within it to increase the memory cap and this usually helped a bit. Being desperate, I decided to try that and off I went to try that. But, that was not so easy. I wandered a bit around the eclipse folder looking for the location of the eclipse.ini but it was nowhere to be found. So I tried searching for it – nop, no luck there as well.
Apparently eclipse.ini is packaged inside the eclipse app so what you need to do is to get inside the eclipse.app package
OR you can use this command:
vi $ECLIPSE_HOME/Eclipse.app/Contents/MacOS/eclipse.ini
after that edit eclipse.ini which you will find in Contents->MacOS folder and increase the memory limits for the following directives (on my case I used these values):
--launcher.XXMaxPermSize 2048m ... -vmargs -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.requiredJavaVersion=1.6 -Xms512m -Xmx850m -XX:PermSize=512m -XX:MaxPermSize=1024mWhile this is good, this is NOT what will actually make your Eclipse fly. The most important part here is the:
-Dosgi.requiredJavaVersion=1.5
now, you have to switch that to 1.6 and make it
-Dosgi.requiredJavaVersion=1.6
Now THAT will make your Eclipse really shine! Just make sure you actually HAVE the JDK 1.6 installed. You can validate this by running “java -version” in the terminal. If you got 10.6 – Snow Leopard though, you are most likely covered.
Also I still have two more tricks that might be useful:
-Xverify:none
Which will skip the class verification stage during class loading. Using -Xverify:none disables Java class verification, which can provide a 10-15% improvement in startup time. However corrupted or invalid class data is not detected when this option is specified. If corrupt class data is loaded, the Java Virtual Machine (JVM) might behave in an unexpected manner, or the JVM might fail.
-XX:+UseParallelGC
Which is known as The parallel scavenge collector. Which is just an improved version of the parallel copying collector (Enabled using -XX:+UseParNewGC), but the algorithm is tuned for gigabyte heaps (over 10GB) on multi-CPU machines.
If you already had that in the eclipse.ini file – well, unfortunately this already has been optimized for you and the only thing you can try from there that we know of is to play with the memmory limits.
Also, I've discovered other options, which I'm not 100% sure how they work together (because I haven't researched them too deep :P), however they might help you out:
-XX:CompileThreshold=5 -XX:MaxGCPauseMillis=10 -XX:MaxHeapFreeRatio=70 -XX:+UseFastAccessorMethods -XX:+CMSIncrementalPacing -XX:+UseG1GC -XX:+UseFastAccessorMethods
Just don't mix them with -XX:+UseParallelGC
