In a discussion with colleagues, it was discovered that different setup schemes for IntelliJ IDEA memory would have different effects on the speed and responsiveness of the IDE.
Don’t be a Scrooge and give your IDE some more memory
Don’t be a miser, save more memory for the IDE.
Yesterday, there was a discussion about whether to customize the memory Settings for IntelliJ IDEA. Some people chose the default Settings, some people made simple changes to the default Settings, and some developers made comprehensive and complex Settings based on their needs. I’m currently working on several microservices projects and an old project, and the client’s core business needs are very large. After a simple setup of the IntelliJ IDEA memory, I can clearly see the improvements in speed and responsiveness of the IDE. But at that time, the author did not make a specific measurement, so this is just a subjective feeling.
However, one of the developers in the discussion sent me a copy of his setup, which was extremely complex, albeit for the same project. I’m not unhappy with my Settings, but am curious to see how these completely different Settings compare to the default Settings provided by JetBrains.
The target
My plan is to test the effect of each setting in a scenario that is close to a daily development project (load a large project, load 2 or 3 microservices, refresh the large project after Git pull) and select the best setting for optimal memory consumption and speed.
Test machines and items
Laptops: MacBook Pro Retina, 2.3ghz Intel Core I7, 16GB 1600Mhz DDR3,SSD Disc, OS X Yosemite
project
Big Project — Monolith, 700,000 lines of code (Java[1] 8 and Groovy), 303 Gradle modules
Two microservices — small projects with approximately 10,000-20,000 lines of code (Java 8 and Groovy), each with a Gradle module
Test scenarios
1. Close all projects in Idea. 2. 4. Close all unrelated projects (Communicators, etc.) 5. Open Idea (test time) 6. Open large project (test time) 7. Check jstat -gcutil 8. Open two microservice projects (test time) 9. Check jstat -gcutil 10. Go back to the large project and click the “Refresh Gradle Project” button (test time) 11. Check the jstat – gcutil
jstat -gcutil
Jstat is a JDK built-in tool that provides real-time command-line monitoring of Java application resources and performance using JVM built-in instructions, including Heap size and garbage collection status. It has a number of options to collect all kinds of data, but I’ll only use them here:
-gcutil :
-gcutil - Summary of garbage collection statistics.
S0: Survivor space 0 utilization as a percentage of the space's current capacity.
S1: Survivor space 1 utilization as a percentage of the space's current capacity.
E: Eden space utilization as a percentage of the space's current capacity.
O: Old space utilization as a percentage of the space's current capacity.
M: Metaspace utilization as a percentage of the space's current capacity.
CCS: Compressed class space utilization as a percentage.
YGC: Number of young generation GC events.
YGCT: Young generation garbage collection time.
FGC: Number of full GC events.
FGCT: Full garbage collection time.
GCT: Total garbage collection time.
Copy the codeThe command produces the following output:
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159 The most important parameters are the number of GC events (YGC and FGC) and the collection time (YGCT and FGCT).Copy the codeThe test set
I set up four different Settings, giving them different names for ease of remembering.
Default (gray)
The default Settings provided by JetBrains:
-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
Copy the codeBig (red label)
Set Xmx to 4096MB and ReservedCodeCacheSize to 1024MB, which is already quite a bit of memory:
-Xms1024m-Xmx4096m-XX:ReservedCodeCacheSize=1024m-XX:+UseCompressedOops
Copy the codeBalanced(blue)
Xmx and Xms are both allocated 2GB, which is a fairly balanced memory consumption:
-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Copy the codeSophisticated (orange logo)
As above, Xmx and Xms both allocate 2GB, but specify different garbage collectors and many different flags for GC and memory management:
-server
-Xms2g
-Xmx2g
-XX:NewRatio=3
-Xss16m
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:ConcGCThreads=4
-XX:ReservedCodeCacheSize=240m
-XX:+AlwaysPreTouch
-XX:+TieredCompilation
-XX:+UseCompressedOops
-XX:SoftRefLRUPolicyMSPerMB=50
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djsse.enableSNIExtension=false
-ea
Copy the codeThis is the author of the test set, in order to perform the test case, you also need to under the ~ / Library/Preferences/IntelliJIdea15 / create a idea. Vmoptions file (this is the path of the Mac OS system Settings, based on your operating system Settings)
Now, execute the test case and compare the results.
The results of
Idea Startup time
As shown in the figure above, boot time is not dependent on memory Settings. Idea is tested for 10 seconds in all scenarios, regardless of memory allocation. This is not surprising, as these Settings do not affect the behavior of the application at this early stage.
The time it takes to load a large project
Now load the Monolith project and its 700,000 lines of code. Finally, there are some differences. The default Settings took almost three times as long. Obviously, such a large code base requires more memory. If we execute:
jstat -gcutil <IDEA_PID>
Copy the codeYou will find that the GC is extremely busy under the default Settings compared to other Settings.
Not only is the total time for GC to free memory very high (almost 50 times), but the average execution time for Full GC is also very, very long. A lot of time is spent on Full GC, which is the main reason for the IDE’s low responsiveness.
Open two microservices in IDEA
Now load the two microservices, open them in IDEA and compare their elapsed time.
In this test case, the difference was clear, with the complex Settings performing best, and the default Settings still losing out to the other two Settings.
Again, use jstat -gcutil
After loading the two microservice projects, let’s check how the GC behaves with three projects open at the same time. When tested, the three different customizations performed almost equally, and the default Settings were simply too weak.
Final race: Reload Monolith
Now I need to get the latest version of the Monolith project from the repository and refresh the Gradle module so that IDEA can see all the new classes.
Important note: The gray bar representing the default Settings is very tall, because IDEA crashed during the refresh process and I was unable to measure the actual time. Obviously, the memory allocated by default is insufficient to perform this operation.
However, from the three customization examples, the large memory configuration takes the least time. So, memory allocation does play a role.
Jstat-gcutil is used for the last time
Since IDEA cannot refresh projects under default Settings, the default Settings were not included in this test.
As you can see from the figure above, the difference between the three is small, but Full GC in the Big configuration has the fastest execution time. In addition, the greater memory of Xmx helps significantly in improving responsiveness.
conclusion
In this brief experiment, you can see that even minor tweaks to IntelliJ IDEA memory can greatly improve IDE performance. Of course, the more memory allocated, the better the performance. However, you will also find that many applications outside the IDE consume memory, so the goal should be to find a balance between improved performance and memory consumption.
In most cases, I think it’s best to set the Xmx value between 2G and 3G. If you have more time you can use Jstat and JVisuALM to check how different JVM Settings affect performance and memory footprint.
Translation: dzone.com/articles/th…
Author: Ha Learns Java