IntelliJ IDEA Memory Optimization Best Practices

Reprinted: http://blog.oneapm.com/apm-tech/426.html
[Editor's note] In a discussion with colleagues, the author of this article found that using different setting schemes for IntelliJ IDEA memory will affect the speed and speed of the IDE. Responsiveness makes a difference.

IntelliJ IDEA Memory Optimization Best Practices Technology Sharing Part 1

Don't be a Scrooge and give your IDE some more memory Don't be a

miser, give your IDE some more memory.

Yesterday, everyone discussed whether to customize IntelliJ IDEA's memory settings. Some people choose the default settings, some people make simple changes to the default settings, and some developers make comprehensive and complex settings based on their needs. The author's current job is to deal with several microservice projects and an old project, and the customer's core business needs are very large. After a simple setting of IntelliJ IDEA memory, the author clearly felt the improvement of the IDE in terms of speed and responsiveness. But at the time, the author did not carry out specific measurements, so this is just a subjective feeling.

However, one of the developers involved in the discussion sent me a copy of his setup, which was extremely complicated, albeit for the same project. I'm not dissatisfied with my settings, but I'm curious how these completely different settings compare to the default settings provided by JetBrains.

Goal The
author 's plan is to test the effect of each setting and select the memory consumption in a scenario close to the daily development project (loading a large project, loading 2 or 3 microservices, and refreshing the large project after git pull). Optimal settings for optimal speed and speed.

Test machines and projects
Laptop: MacBook Pro Retina, 2.3GHz Intel Core i7, 16GB 1600Mhz DDR3, SSD Disc, OS X Yosemite
Project

Big Project - Monolith, 700k lines of code (Java 8 and Groovy), 303 Gradle modules

Two Microservices - -About 10,000 - 20,000 lines of code (Java 8 and Groovy) small projects, each with a Gradle module

Test scenario
Close all projects in Idea Set
based on test file idea.vmoptions
Restart computer Close all irrelevant projects after
startup (communicators etc.)
open Idea (test time)
open big project (test time)
check jstat -gcutil
open two microservice projects (test time)
check jstat -gcutil
go back to big project and click "Refresh Gradle Project" button (test time) )
Check jstat -gcutil
jstat -gcutil
jstat is a tool that comes with the JDK. It mainly uses the built-in JVM instructions to monitor the resources and performance of Java applications in real time from the command line. It also includes the monitoring of Heap size and garbage collection status. It has many options to collect various data (full documentation), but only used 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. 
The output of this command is as follows:

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 
In this article, the most important parameters are GC events ( YGC and FGC ) Times and collection times (YGCT and FGCT).

Test Setup
I set up four different setups, giving them different names for easy recall.

Default (marked in gray)
The default settings provided by JetBrains:

-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops
Big (big) (marked in red)
for Xmx with 4096MB, ReservedCodeCacheSize set to 1024MB, this That 's quite a lot of memory:

-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Balanced (blue mark)
Both Xmx and Xms allocate 2GB, which is a fairly balanced memory consumption:

-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops
Sophisticated (complex) (in orange)
As above, both Xmx and Xms 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
The above is the author's test settings. In order to execute this test case, you need to create an idea.vmoptions file under ~/Library/Preferences/IntelliJIdea15/ (this is the path setting under Mac OS system, check this article, Set it based on your OS)

Now, execute the test case and compare the results.

Results
Idea startup time
IntelliJ IDEA Memory Optimization Best Practices Technology Sharing Part 2

As shown in the figure above, startup time does not depend on memory settings. Idea's test time in all scenarios is 10 seconds, no matter how much memory is allocated. This is not surprising, since at this early stage, these settings don't affect the behavior of the app.

Time taken to load large project
Now load the Monolith project and its 700k lines of code. Finally, some differences emerged. The default setting took almost 3 times as long. Obviously, such a large codebase requires more memory. If we execute:

jstat -gcutil <IDEA_PID>  we
will find that the GC gets very busy with default settings compared to other settings.

IntelliJ IDEA memory optimization best practice technology sharing sheet 3

IntelliJ IDEA memory optimization best practice technique sharing sheet 4

Not only the total time for GC to release memory is very high (almost 50 times), but the average execution time of Full GC is also very high. very long. A lot of time is spent on Full GC, which is the main reason for the slow IDE response.

Open the two microservices in IDEA
Now load the two microservice projects, open them in IDEA and compare the time they take.

IntelliJ IDEA Memory Optimization Best Practices Technology Sharing Part 5

In this test case, the difference is still very obvious, the complex settings perform best, and the default settings still lose to the other two settings.

After loading the two microservice projects using jstat –gcutil again
, let’s check the performance of GC when three projects are opened at the same time. After testing, it was found that the performance of 3 different custom settings is almost the same, and the default settings are simply weak.

IntelliJ IDEA Memory Optimization Best Practices Technology Sharing Sheet 6

IntelliJ IDEA Memory Optimization Best Practice Techniques Sharing Sheet 7 The

Final Race: Reloading Monolith
Now, I need to get the latest version of the Monolith project from the repository, and refresh the Gradle module, This way IDEA can see all the new classes.

IntelliJ IDEA Memory Optimization Best Practices Technology Sharing Sheet 8

Important : The gray bar representing the default setting is very high, because IDEA crashes during the refresh process, and I cannot measure the actual time. Apparently, the default allocated memory is not enough to perform the operation.

But from the three custom examples, it can be found that the large memory configuration takes the shortest time. So, memory allocation still plays a role.

The last time I used jstat-gcutil
because IDEA cannot refresh the project under the default settings, so the default settings for this test are not included.

IntelliJ IDEA memory optimization best practice technology sharing sheet 9

IntelliJ IDEA memory optimization best practice technique sharing sheet 10

As can be seen from the above figure, the difference between the three is not large, but the execution time of Full GC under the Big configuration is the fastest. In addition, the larger Xmx memory helps greatly in responsiveness.

Summary
In this brief experiment, you can see that even fine-tuning IntelliJ IDEA memory can greatly improve IDE performance. Of course, the more memory allocated, the better the execution. However, you will also find that many other applications outside the IDE also consume memory, so your goal should be to find a balance between improving performance and memory consumption. In my opinion, setting the Xmx value between 2G and 3G is optimal in most cases. If you have more time you can use jstat and jvisualm to check how different JVM settings affect performance and memory usage.

Discussion How is
your idea.vmoptions configured? Do you have other ways to improve the performance of InteliJ IDEA? Let's discuss it together