This is what I found on the Internet about Eclipse optimization method, very to the force, special turn to make a collection.
Start by understanding some of the related concepts in the JVM:
Xms: Minimum heap size
XMX: Maximum Heap Size
XMN: Young generation Heap Size
XSS: The heap size per thread
PermSize: initial persistent generation size
MaxPermSize: Maximum persistent generation size
The general XMS, XMX settings are the same, permsize, maxpermsize settings are the same, so as to avoid the scale heap size of performance loss.
First open the Eclipse.ini in the Eclipse installation root, plus the configuration:
-xloggc:gc.log
-xx:+printgctimestamps
-xx:+printgcdetails
The goal is to run eclipse with a verbose GC process.
Start eclipse, and then open Gc.log. Once you've started, you've done GC dozens of times, including many times full GC, and started optimizing ...
Solve the full GC problem first:
......
3.159: [Full GC 3.159: [tenured:22716k->26133k (35780K), 0.1116536 secs] 38493k->26133k (51908K), [Perm:20479k-> 20479K (20480K)], 0.1117614 secs] [times:user=0.11 sys=0.00, real=0.11 secs]
3.706: [Full GC 3.706: [tenured:26133k->27935k (43556K), 0.1235449 secs] 40042k->27935k (63204K), [Perm:24575k-> 24575K (24576K)], 0.1236474 secs] [times:user=0.13 sys=0.00, real=0.13 secs]
......
As can be seen on the GC log, the full GC is mainly for the tenured, Perm District GC, good that first adjust the perm size, specify a sufficient amount of persistent generation area, Eclipse.ini added:
-xx:permsize=128m
-xx:maxpermsize=128m
Start again see Gc.log,full GC is gone, but there are many more common GC, which still need further optimization.
Eclipse's initial heap size is allocated very small and therefore not conducive to the allocation of the young generation heap size, if the set of young generation heap size xmn is greater than the minimum heap size xms,eclipse will fail to start.
Therefore, the XMS is adjusted to 512m and the GC is significantly reduced after restarting.
Finally adjust the xmn, the young generation heap size, after repeated comparisons, found that the setting "-xmn256m" effect is optimal.
Optimized GC logs:
3.203: [GC 3.204: [defnew:209776k->26176k (235968K), 0.0876304 secs] 209776k->27184k (498112K), 0.0876921 secs] [ times:user=0.09 sys=0.00, real=0.09 secs]
5.422: [GC 5.422: [defnew:235968k->12433k (235968K), 0.0989335 secs] 236976k->39296k (498112K), 0.0990229 secs]
In nearly 6 seconds of start-up time, Eclipse has only done 2 ordinary GC recovery, how effective it is!
In general, when you do not set up eclipse, the use of eclipse will always feel that the boot is slow, good card, in fact, as long as the relevant parameters of eclipse configuration, there will be a great improvement.
Faster start-up speed
1. When eclipse starts, it always searches for the JRE it runs on, often the search process slows eclipse startup. (When not set, wait for the 2-3s to appear the progress bar, after set up directly appears the progress bar)
Just add the-VM parameter to the Eclipse.ini.
2. Cancel all plug-ins to be activated at startup (same as when activation occurs) and other related actions that are performed at startup.
3. Turn off Automatic Updates
Reduce problems with Eclipse cards caused by JVM memory reclamation
This is mainly the JVM in the client mode, when the memory is collected, will stop all the other work, with the recovery to perform other tasks, during which eclipse is stuck. Therefore, the proper increase in the amount of memory requested by the JVM to reduce the number of times it is recycled or even not recycled, there will be a noticeable improvement in the card phenomenon.
The heap memory is set primarily by the following JVM parameters:
| -xmx512m |
maximum total heap memory, generally set to physical memory of the quarter |
| -xms51 2m |
Initial total heap memory, which is typically as large as the maximum heap memory, so that the heap size is not adjusted to the current heap usage |
| -xmn192m |
Young with heap memory, Sun officer Party recommended for the entire heap 3/8 |
| heap Memory composition |
Total heap memory = Young with heap memory + aged with heap memory + persistent heap memory |
| Young in-heap The Save |
object is placed here when it was first created |
| old age with heap memory |
objects are placed here before they are actually recycled |
| Persistent heap Memory |
class file, metadata, etc. |
| -xx:permsize=128m |
Initial size of the persistent heap |
| -xx:maxpermsize=128m |
the maximum size of the persisted heap, and eclipse defaults to 256m. If you want to compile this kind of JDK, make sure to set this up very large, because it has too many classes. |
My configuration (2g memory for Notebooks):
There are other relevant parameters to look at the following reference material, very inspiring:
-XX:+USEPARALLELGC using concurrent Memory reclamation
-XX:+DISABLEEXPLICITGC Disabling display memory recycling for System.GC ()
Eclipse-related settings to reduce card behavior
1. Turn off automatic builds. When enabled, eclipse will automatically build the entire project for us every time you save it, so that for large projects, it will cause a lot of cards for each save. In fact, auto-build is completely unnecessary, as long as it is OK to build once before running, Eclipse will be built for us automatically before running, so shutting down is the smartest choice.
2. Turn off spell check settings
reference materials
JVM Startup Parameters Daquan: http://www.blogjava.net/midstr/archive/2008/09/21/230265.html
Some knowledge of the JVM structure (the composition of the heap): Http://hllvm.group.iteye.com/group/wiki/2905-JVM
JVM Heap Knowledge: http://ruijf.iteye.com/blog/1028455
Eclipse Startup tuning: http://www.iteye.com/topic/756538
Eclipse comes with Help contents (search for "Running Eclipse" to find boot-related configuration)
This article turns from
http://blog.csdn.net/tomato8524/article/details/7428742
http://blog.csdn.net/tomato8524/article/details/7428793
Eclipse "Go" Eclipse optimized configuration