Turbo-charging Eclipse
I changed my eclipse.ini file around after researching some jvm option settings. I primarily use CFEclipse, Mylyn, and Subclipse. I am not a jvm options expert, but I referenced several articles. Before modifying the eclipse.ini file please back it up. The ini file can be error prone with returns and spaces. My simple test shows an improvement in times. If someone knows how to test and benchmark Eclipse startup and performance better I would be interested in learning how.
eclipse.ini file
-nosplash
-vmargs
-XX:+AggressiveHeap
-XX:+AggressiveOpts
-XX:+UseParallelOldGC
-XX:ParallelGCThreads=2
-XX:ThreadPriorityPolicy=1
-Xverify:none
What the options/settings do (these explainations are from the articles listed below):
-XX:+AggressiveHeap
The -XX:+AggressiveHeap option inspects the machine resources (size of memory and number of processors) and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs. It was originally intended for machines with large amounts of memory and a large number of CPUs, but in the J2SE platform, version 1.4.1 and later it has shown itself to be useful even on four processor machines. With this option the throughput collector (-XX:+UseParallelGC) is used along with adaptive sizing (-XX:+UseAdaptiveSizePolicy). The physical memory on the machines must be at least 256MB before AggressiveHeap can be used. The size of the initial heap is calculated based on the size of the physical memory and attempts to make maximal use of the physical memory for the heap (i.e., the algorithms attempt to use heaps nearly as large as the total physical memory).
UseAdaptiveSizePolicy
A feature available with the throughput collector in the J2SE platform, version 1.4.1 and later releases is the use of adaptive sizing (-XX:+UseAdaptiveSizePolicy), which is on by default. Adaptive sizing keeps statistics about garbage collection times, allocation rates, and the free space in the heap after a collection. These statistics are used to make decisions regarding changes to the sizes of the young generation and tenured generation so as to best fit the behavior of the application. Use the command line option -verbose:gc to see the resulting sizes of the heap.
UseParallelGC
Use the Parallel Scavenge garbage collector
UseParallelOldGC
Use the Parallel Old garbage collector
-XX:+AggressiveOpts
Turns on point performance optimizations that are expected to be on by default in upcoming releases. The changes grouped by this flag are minor changes to JVM runtime compiled code and not distinct performance features (such as BiasedLocking and ParallelOldGC). This is a good flag to try the JVM engineering team's latest performance tweaks for upcoming releases. Note: this option is experimental! The specific optimizations enabled by this option can change from release to release and even build to build. You should reevaluate the effects of this option with prior to deploying a new release of Java.
ParallelGCThreads
Number of parallel threads parallel gc will use
ThreadPriorityPolicy
0 : Normal. VM chooses priorities that are appropriate for normal applications. On Solaris NORM_PRIORITY and above are mapped to normal native priority. Java priorities below NORM_PRIORITY" map to lower native priority values. On Windows applications" are allowed to use higher native priorities. However, with ThreadPriorityPolicy=0, VM will not use the highest possible" native priority, THREAD_PRIORITY_TIME_CRITICAL, as it may interfere with system threads. On Linux thread priorities are ignored because the OS does not support static priority in SCHED_OTHER scheduling class which is the only choice for" non-root, non-realtime applications. 1 : Aggressive. Java thread priorities map over to the entire range of native thread priorities. Higher Java thread priorities map to higher native thread priorities. This policy should be used with care, as sometimes it can cause performance degradation in the application and/or the entire system. On Linux this policy requires root privilege.
Links used for gathering information on the settings
The most complete list of -XX options for Java 6 JVM
Java Garbage Collection Tuning
Turbo-charging Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers
Java Tuning White Paper
Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine
——
I am using a crude benchmark test against my Windows XP laptop using eclipse java -jar startup.jar -debug
| turbo-charged eclipse.ini | eclipse-SDK-3.3.2-win32 eclipse.ini | |||
| Time to load bundles | 15 | 16 | 16 | 15 |
| Starting application | 640 | 625 | 1094 | 938 |
| Application Started | 5640 | 5641 | 10328 | 8245 |




Posted under: 


Mike, have you actually noticed improved performance with all these tweaks?
I pass several of these on the command line. I'm curious as well if you notice any noticeable speed up. I may include a link to here from the CFEclipse wiki :)
I added a crude test but would like to see the time after "refreshing workspace" is finished. Not sure if they are "noticeable" but to me it seems to be. I started tweaking the ini file cause I was getting some heap space errors with running Flex.
Same test on my Ubuntu laptop (some reason it didn't display Application Started)
Turbo-Charged eclipse.ini
Time to Load bundles = 9,10,11,11
Starting Application = 1278,1276,1259,1461
Normal ini
Time to Load bundles = 31,10,11,22
Starting Application = 3442,2346,2700,1975
I know this is an old thread, but to answer Marc and Jim's questions, yes, I notice a HUGE difference. I don;t have any benchmark numbers, but just watching Eclipse load, it is noticeably faster.
http://eclipse.dzone.com/news/turbo-charging-eclipse - with some good comments
Mike, I just upgraded my MBP to Snow Leopard and my Eclipse installation failed to load. I narrowed it down to the -XX:+UseParallelOldGC option. With that option it won't start up, without it it's fine. Not sure what that means, but I thought I'd post a comment here, as I think I may have picked up that option originally from this post.
Hey Bob, been meaning to send you an email about ValidateThis, I'll do that now :-) Must be -XX:+UseParallelOldGC isn't valid with your jvm.
I went out on a limb and cut and pasted these options into eclipse.ini and it does make a big difference in startup time. Thanks for sharing.
Randy
Thanks for the comment Randy. You might also look at http://stackoverflow.com/questions/142357/what-are-the-best-jvm-settings-for-eclipse and http://www.henke.ws/post.cfm/Turbo-charging-Eclipse
Hi Mike,
I used your eclipse.ini suggestions with;
eclipse Helios and the public beta of CFBuilder 2.0
Like Bob, before me, I noted that -XX:+UseParallelOldGC will stop eclipse from loading on my Mac.
In the interest of people "popping in" after me here is my eclipse.ini for Mac OS 10.6.x (Snow Leopard)
I use the jee bundle of eclipse so it has Mylyn (and others) already in the bundle.
I also use the Subclipse and MXUnit plugins.
I have actually no idea what any of the "other" settings do, but a completely stripped down ini file (Eg if I simply copy/paste yours - even without the use of UseParallelOldGC, also sees eclipse fail to load)
So this "seems" to be the minimum that I need to successfully load / use eclipse.
The difference is, frankly, amazing. Eclipse / CFBuilder just flies.
Lastly, as a point of interest, I have 4GB RAM in my Mac and the heap status reads;
xxm of 1876m - not sure how it comes to that "magical" number...shrugs...but like I said it really makes CFBuilder simply awesome to use.
Thanks very much for the article / research that went into this.
-startup
../../../plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx.x86_64_1.1.2.R36x_v20101019_1345
-nosplash
--launcher.defaultAction
openFile
-product
org.eclipse.epp.package.jee.product
-vmargs
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Dosgi.requiredJavaVersion=1.5
-XX:+AggressiveHeap
-XX:+AggressiveOpts
-XX:ParallelGCThreads=2
-XX:ThreadPriorityPolicy=1
-Xverify:none
Oh - Seems I can't copy/paste correctly, sorry.
I ALWAYS have to add the -XX:MaxPermSize, argument.
Without it I get out of memory errors and eclipse hangs after minimal usage.
I found -XX:MaxPermSize=128m "somewhere" on the internet, when I first started having out of memory issues.It was especially curious to me when I increased the heap to 1GB and I still got the out of memory errors.
The research revealed that this setting is used for "setting aside" a bucket of memory for loading classes (plug-ins etc) - as opposed to "working" space.
Since I have 4GB RAM - I simply doubled it - just to be sure...
-XX:MaxPermSize=256m
<a href="http://www.celexanorxonline.net/#buy-citalopram">buy citalopram</a>, citalopram online, http://www.celexanorxonline.net/#citalopram-online
rv <a href="http://www.lunestaonlinesales.net/#eszopiclone-no-prescription">eszopiclone no prescription</a>, eszopiclone online, http://www.lunestaonlinesales.net/#eszopiclone-online
n <a href="http://www.valtrexonlinesale.net/#valacyclovir-no-prescription">valacyclovir no prescription</a>, valacyclovir online, http://www.valtrexonlinesale.net/#valacyclovir-online
r <a href="http://www.prednisoloneforcheap.net/#prednisone-prednisolone">prednisone prednisolone</a>, prednisone cost, http://www.prednisoloneforcheap.net/#prednisone-cost
r
j <a href="http://www.playinginpeoria.org/more.html>">generic cymbalta online</a>, generic duloxetine, http://www.playinginpeoria.org/>
s <a href="http://britpoppedia.com/homework.html"></a>, , http://britpoppedia.com/homework.html