[RPM] optimized Eclipse performance tuning to date with Eclipse.ini

Recently, Eclipse (eclipse-jee3.5) has been running very slowly (possibly too many plug-in installations), so it has been given an opportunity to tune up to improve productivity

is without any tuning of Eclipse's GC case (using the JVISUALVM command, install the Visual GC plugin)

After terminal input: JVISUALVM is running, the plugin->visual GC, installed.

After you start eclipse, run at Terminal: ps-ef | grep eclipse, and then select the Eclipse PID program double-click in the JVISUALVM application column to view the chart on the visual GC.

-xms1024m
-xmx1024m

corresponding to the old area in the diagram;

-xx:newsize=768m
-xx:maxnewsize=768m

corresponding to the Eden area in the diagram;

-xx:permsize=200m
-xx:maxpermsize=200m

corresponding to the perm area in the graph;

As you can see, the start-up process is 38 times young gc,11 times full GC
To view GC details, add the following parameters to the Eclipse.ini:
-verbose:gc
-xx:+printgcdetails
-xx:+printgcdatestamps
-xloggc:d:/soft/eclipse-jee/gc.log
The GC content is as follows:

As you can see from the GC log:
(1) Young district started as 4928K, and continued to be insufficient, thus causing constant young GC
(2) Full GC, the old area of the space to increase capacity, so old area space is not enough
To prevent this from happening, add the following parameters:
-xms768m
-xmx768m
-xx:newsize=512m
-xx:maxnewsize=512m
The results of this adjustment are as follows:

As can be seen, young GC is not, but why still 11 times full GC?
The following is a log of this GC:

From the Gc.log, it can be seen that because there is no space in the perm area, resulting in the full GC, so the perm area is enlarged and fixed size
Add the following parameters:
-xx:permsize=96m
-xx:maxpermsize=96m
The results of this adjustment are as follows:

As can be seen, there is no full GC, and young GC only once, has a certain effect
The GC problem was solved at startup and now looks at other issues:

As you can see, if ClassLoader loads the class faster, it should save some time.
Add the following parameters:
-xverify:none (Turns off Java bytecode validation, which speeds up class loading)

Compare the above two graphs
First: Average loading time for each class, 54.615/10950 = 0.0049876712328767s
Second: Average loading time for each class, 34.498/9484 = 0.0036374947279629s
As you can see, there are some performance improvements in how much
Given that eclipse is running for a long time, the other possible adjustments are as follows:
(1) Close System.GC ()
(2) Improved JIT compilation of some code in eclipse
(3) Optimize the garbage collector to reduce the time that garbage collection causes the application not to respond
for (1), add the following parameters:
-xx:+disableexplicitgc
for (2), the startup speed is affected, but because Eclipse is long running, this optimization is necessary:
-XX:COMPILETHRESHOLD=100 (How many times a method call will be compiled cost to machine code)

As you can see, the number and time of compilation methods increase significantly
for (3), swapping CMS collectors should be better than serial collectors, adding the following parameters:
-xx:+useparnewgc
-xx:+useconcmarksweepgc
-xx:cmsinitiatingoccupancyfraction=80
At this point, tuning ends

Summarize the parameters of the join as follows:
-verbose:gc
-xx:+printgcdetails
-xx:+printgcdatestamps
-xloggc:d:/soft/eclipse-jee-galileo-win32/eclipse/gc.log
-xms512m
-xmx512m
-xx:newsize=256m
-xx:maxnewsize=256m
-xx:permsize=96m
-xx:maxpermsize=96m
-xx:+disableexplicitgc
-xx:compilethreshold=100
-xverify:none
-xx:+useparnewgc
-xx:+useconcmarksweepgc
-xx:cmsinitiatingoccupancyfraction=80

http://blog.csdn.net/gtuu0123/article/details/6720253

Refer to the Eclipse.ini for the above content:

1, small memory, good running situation

-clean
-startup
Plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.200.v20130807-1835
-product
Org.eclipse.epp.package.cpp.product
--launcher.defaultaction
OpenFile
-showsplash
Org.eclipse.platform
--launcher. Xxmaxpermsize
256m
--launcher.defaultaction
OpenFile
--launcher.appendvmargs
-vmargs
-dosgi.requiredjavaversion=1.6
-xms512m
-xmx512m
-xx:newsize=256m
-xx:maxnewsize=256m
-xx:permsize=96m
-xx:maxpermsize=96m
-xx:+disableexplicitgc
-xx:compilethreshold=100
-xverify:none
-xx:+useparnewgc
-xx:+useconcmarksweepgc
-xx:cmsinitiatingoccupancyfraction=80

2. Large Memory

-clean
-startup
Plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.200.v20130807-1835
-product
Org.eclipse.epp.package.cpp.product
--launcher.defaultaction
OpenFile
-showsplash
Org.eclipse.platform
--launcher. Xxmaxpermsize
256m
--launcher.defaultaction
OpenFile
--launcher.appendvmargs
-vmargs
-dosgi.requiredjavaversion=1.6
-xms1600m
-xmx1600m
-xx:newsize=800m
-xx:maxnewsize=800m
-xx:permsize=256m
-xx:maxpermsize=256m
-xx:+disableexplicitgc
-xx:compilethreshold=100
-xverify:none
-xx:+useparnewgc
-xx:+useconcmarksweepgc
-xx:cmsinitiatingoccupancyfraction=80

3, large memory, self-made, may be optimized unreasonable

-clean
-startup
Plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.1.200.v20130807-1835
-product
Org.eclipse.epp.package.cpp.product
--launcher.defaultaction
openFile
-showsplash
Org.eclipse.platform
--launcher. Xxmaxpermsize
256m
--launcher.defaultaction
openFile
--launcher.appendvmargs
-vmargs
- dosgi.requiredjavaversion=1.6
-xx:maxpermsize=256m
-xms40m
-xmx2048m
-xss1024k
-xss1024k
-XX : +DISABLEEXPLICITGC
-xx:compilethreshold=100
-XX:+USEPARNEWGC
-XX:+USECONCMARKSWEEPGC
-XX: cmsinitiatingoccupancyfraction=80
-xverify:none