An analysis of the Eclipse method with faster configuration

Many people feel that their elipse start is slow, in fact, not because of the plug-in too many or imported items are a bit large, but because the parameters of the unreasonable settings caused. Can be added in Eclipse.ini
-xloggc:gc.log look at the startup log. Let's just say that by optimizing the configuration to save Eclipse startup time, the data in this article is my native environment, my native memory is 3.16G.
First-time optimization:Set the-XMS (Initialize heap size)-xmx (JVM maximum heap size) to 512m to avoid frequent GC. As shown below:
-xms512m
-xmx512m
-verbose:gc
-xx:+printgcdatestamps
-xx:+printgcdetails
-xloggc:gc.log
When I restarted eclipse, the full GC was 8 times, and the number of Minitor GC was 3. The logs are as follows:
2014-06-09t20:39:00.480+0800:1.850: [GC 1.850: [defnew:139776k->17472k (157248K), 0.0613123 secs] 139776k-> 20106K (506816K), 0.0614226 secs] [times:user=0.06 sys=0.00, real=0.06 secs]
2014-06-09t20:39:01.214+0800:2.597: [Full GC 2.597: [tenured:2634k->35922k (349568K), 0.1242231 secs] 81163k-> 35922K (506816K), [perm:16383k->16383k (16384K)], 0.1243415 secs] [times:user=0.11 sys=0.01, real=0.13 secs]
2014-06-09t20:39:01.698+0800:3.075: [Full GC 3.075: [tenured:35922k->38486k (349568K), 0.1086032 secs] 121915k-> 38486K (506816K), [perm:20479k->20479k (20480K)], 0.1087152 secs] [times:user=0.11 sys=0.00, real=0.11 secs]
2014-06-09t20:39:02.026+0800:3.408: [Full GC 3.408: [tenured:38486k->39671k (349568K), 0.1166902 secs] 52893k-> 39671K (506816K), [perm:24575k->24575k (24576K)], 0.1168707 secs] [times:user=0.13 sys=0.00, real=0.13 secs]
2014-06-09t20:39:02.558+0800:3.926: [Full GC 3.926: [tenured:39671k->41312k (349568K), 0.1572323 secs] 57131k-> 41312K (506816K), [perm:28671k->28650k (28672K)], 0.1573102 secs] [times:user=0.16 sys=0.00, real=0.16 secs]
2014-06-09t20:39:03.276+0800:4.653: [Full GC 4.653: [tenured:41312k->44308k (349568K), 0.1656481 secs] 87405k-> 44308K (506816K), [perm:32767k->32767k (32768K)], 0.1657328 secs] [times:user=0.17 sys=0.00, real=0.17 secs]
2014-06-09t20:39:04.058+0800:5.439: [GC 5.439: [defnew:139776k->17472k (157248K), 0.0356182 secs] 184084k-> 62657K (506816K), 0.0357149 secs] [times:user=0.05 sys=0.00, real=0.05 secs]
2014-06-09t20:39:04.105+0800:5.475: [GC 5.475: [defnew:19934k->7k (157248K), 0.0245383 secs] 65119k->62662k ( 506816K), 0.0246034 secs] [times:user=0.02 sys=0.00, real=0.02 secs]
2014-06-09t20:39:04.136+0800:5.507: [Full GC 5.507: [tenured:62654k->62672k (349568K), 0.1803366 secs] 68235k-> 62672K (506816K), [perm:36863k->36863k (36864K)], 0.1804263 secs] [times:user=0.17 sys=0.00, real=0.17 secs]
2014-06-09t20:39:04.839+0800:6.215: [Full GC 6.215: [tenured:62672k->64003k (349568K), 0.2267431 secs] 198067k-> 64003K (506816K), [perm:40959k->40959k (40960K)], 0.2268157 secs] [times:user=0.23 sys=0.00, real=0.23 secs]
2014-06-09t20:39:06.417+0800:7.796: [Full GC 7.796: [tenured:64003k->71144k (349568K), 0.3148881 secs] 182608k-> 71144K (506816K), [perm:45055k->45035k (45056K)], 0.3149710 secs]
From the log analysis can be seen: Trigger full GC culprit is perm, this is not set, so should continue to optimize!
Second Optimization: Sets the initialization size and maximum size of the persistence to 512m. As shown below:
-xms512m
-xmx512m
-xx:permsize=512m
-xx:maxpermsize=512m
-verbose:gc
-xx:+printgcdatestamps
-xx:+printgcdetails
-xloggc:gc.log
2014-06-09t20:43:29.442+0800:1.872: [GC 1.872: [defnew:139776k->17472k (157248K), 0.0614285 secs] 139776k-> 20106K (506816K), 0.0615441 secs] [times:user=0.06 sys=0.00, real=0.06 secs]
2014-06-09t20:43:30.426+0800:2.852: [GC 2.852: [defnew:157248k->17472k (157248K), 0.0714705 secs] 159882k-> 37813K (506816K), 0.0715851 secs] [times:user=0.06 sys=0.02, real=0.08 secs]
2014-06-09t20:43:32.176+0800:4.608: [GC 4.608: [defnew:157248k->17472k (157248K), 0.0846898 secs] 177589k-> 59609K (506816K), 0.0848035 secs] [times:user=0.09 sys=0.00, real=0.09 secs]
2014-06-09t20:43:32.676+0800:5.099: [GC 5.099: [defnew:157248k->3513k (157248K), 0.0443054 secs] 199385k-> 63063K (506816K), 0.0444509 secs] [times:user=0.05 sys=0.00, real=0.05 secs]
2014-06-09t20:43:33.285+0800:5.705: [GC 5.705: [defnew:143289k->10365k (157248K), 0.0427973 secs] 202839k-> 69914K (506816K), 0.0428756 secs]
The full GC disappears and comes 5 times minor GC. From the log analysis can be seen: the frequent minor GC is not set by the new generation of automatic allocation caused.
third-time optimization:-xmn256m Set the Cenozoic size to 256M. Okay, just 3 times minor GC. The logs are as follows:
2014-06-09t20:45:29.204+0800:2.500: [GC 2.500: [defnew:209792k->26176k (235968K), 0.0951747 secs] 209792k-> 35901K (498112K), 0.0952914 secs] [times:user=0.09 sys=0.00, real=0.09 secs]
2014-06-09t20:45:31.220+0800:4.515: [GC 4.515: [defnew:235968k->22389k (235968K), 0.1084576 secs] 245693k-> 58147K (498112K), 0.1085766 secs] [times:user=0.11 sys=0.00, real=0.11 secs]
2014-06-09t20:45:32.001+0800:5.302: [GC 5.302: [defnew:232181k->5280k (235968K), 0.0570383 secs] 267939k-> 63248K (498112K), 0.0571581 secs]
The final configuration is as follows:
-xmn256m
-xms512m
-xmx512m
-xx:permsize=512m
-xx:maxpermsize=512m
-verbose:gc
-xx:+printgcdatestamps
-xx:+printgcdetails
-xloggc:gc.log