Tuning Eclipse Performance and Avoiding OutOfMemor

At 12:35 AM on Jan 16, 2006, Riyad Kalla Javalobby Editors wrote:

Many Eclipse users have adjusted their VM heap size when launching Eclipse by way of the -vmargs -Xmx256m argument. Some have done it to avoid OutOfMemoryException s, to tweak performance or just as good preventative measure for larger installs. However, most users have never worried before about the size of their VM's permSpace or even had a reason to care, this article will hopefully shed some light on situations when you should care and how to weak your heap and perm settings to get some performance gains in Eclipse.
Combating OutOfMemoryExceptions

A majority of OutOfMemoryException s when using Eclipse are caused by too little heap space for your VM. In this case the old wisdom of adjusting your maximum heap space with something like -vmargs -Xmx256m is still good advice; giving your Java apps more space to run in always helps performance. However, there are situations where even with an enourmous heap size you can still end up with OutOfMemoryException s in your workbench. The reason for this is that your VM is not running out of heap space, but is instead running out of what is known as permSpace . The VM's permSpace is the area of the VM that is used to store data structures and class information (not instances, but the class definitions themselves). In the case of a large enough Java application that may contain 10s of thousands of class files that must be loaded you start to see how the VM can physically run out of space storing all of that information into the default permSpace . If you have run into a situation where you have run out of permSpace you will want to adjust your Eclipse shortcut, eclipse.ini , or startup script to include the argument -XX:MaxPermSize=64m ; generally speaking the more memory you give the VM, the more performant it will be. Tuning this value can help you find what works best for your Eclipse install.
Improving Performance

Now let's assume that you are not encountering any exceptions and Eclipse is running just fine, but you would like to improve the performance. I have found 2 rules of thumb when tweaking the heap size and permSize for Eclipse to maximize performance, and that is to 1) give the VM as much ram as you can spare and 2) set your min and max values to the same amounts to avoid resizing. While neither of these guidelines are revolutionary I have found using them both to really help improve performance; in the case of MyEclipse 4.0.3 on Eclipse 3.1 my subjective perception of the performance increase is anywhere from 50% to a 100% increase on my machine (your mileage may varry depending on hardware, current arguments, etc).

For a machine with 512MB of ram with the developer mainly using just Eclipse (any maybe a browser and IM) I would suggest the following arguments: -vmargs -Xms256m -Xmx256m -XX:PermSize=64m -XX:MaxPermSize=64m

For a machine with 1024MB of ram with the similar run case as described above I would suggest: -vmargs -Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m

and for machines with anymore ram than what I outlined above, adjust to fit your preferences. I have 4GB of ram in my machine and use a heap size of 1024m and a permSize of 512m. You may need to go through a few test runs with different settings to find which one works best for your computer. You may find that only using 256m heap space is sufficient while you end up needing to increase your permSize to 128m. I'll leave it up to you to decide.
Conclusion

I hope some of you have found this tip handy. I know adjusting memory arguments is a topic that has been discussed to death since the dawn of Java, but I also know the vast majority of Eclipse users I help have no idea how to adjust the command line arguments that Eclipse uses nor do they understand why they would adjust them. This tip is also intended for folks that were never aware of the permSize arguments and what they can do for runtime performance as well as avoiding mysterious OutOfMemoryException s that make no sense.

I would encourage you all to share your own performance tweaks in your responses as I may have missed some really good arguments here that have helped you see some noticable improvements in performance or reliability. Thanks for reading.