How Memory Tweaks Transform IntelliJ IDEA Performance: A Real‑World Test

Background

The author noticed that changing IntelliJ IDEA's memory settings can significantly affect the IDE's speed and responsiveness. To verify this observation, a series of controlled tests were designed.

Goal

Evaluate four memory configurations in a realistic development scenario—loading a large monolithic project, two micro‑service projects, performing a git pull, and refreshing the Gradle modules—to determine which setting offers the best balance of memory consumption and performance.

Test Environment

Machine: MacBook Pro Retina, 2.3 GHz Intel Core i7, 16 GB DDR3, SSD, macOS Yosemite

Projects

Monolith: ~700 k lines of Java 8 & Groovy code, 303 Gradle modules

Two micro‑services: each 10 k–20 k lines of Java 8 & Groovy, single Gradle module each

Test Procedure

Close all projects in IDEA

Apply the idea.vmoptions file for the current configuration

Reboot the computer

Close unrelated applications (e.g., communicators)

Launch IDEA and record startup time

Open the monolith project and record loading time

Run jstat -gcutil and capture output

Open the two micro‑service projects and record loading times

Run jstat -gcutil again

Refresh the monolith project (Gradle refresh) and record the time

Run jstat -gcutil a final time

Understanding jstat -gcutil

The jstat tool reports JVM garbage‑collection statistics. The options used in this test focus on the -gcutil summary, which outputs percentages for survivor spaces (S0, S1), Eden (E), Old generation (O), Metaspace (M), Compressed Class Space (CCS), and counts/times for young and full GC events (YGC, YGCT, FGC, FGCT, GCT).

S0   S1   E    O    M    CCS  YGC YGCT FGC  FGCT  GCT

Sample output (values are percentages or counts):

89.70 0.00 81.26 74.27 95.68 91.76 40 2.444 14 0.715 3.159

The most critical metrics for this study are the number of GC events (YGC, FGC) and their total collection times (YGCT, FGCT).

Configurations Tested

Default (gray)

-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops

Big (red)

-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops

Balanced (blue)

-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops

Sophisticated (orange)

-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

To run the tests, an idea.vmoptions file was placed in ~/Library/Preferences/IntelliJIdea15/ (path varies by OS).

Results

IDE Startup Time

All configurations showed the same startup time of about 10 seconds, indicating that early‑stage IDE launch is not affected by memory allocation.

Loading the Monolith Project

The default configuration took roughly three times longer than the custom settings. The jstat output showed a dramatic increase in GC activity for the default setup.

jstat -gcutil <IDEA_PID>

The default configuration generated far more Full GC events, and each Full GC took significantly longer, which explains the slower IDE responsiveness.

Opening Two Micro‑Service Projects

When both micro‑services were opened, the sophisticated configuration performed best, while the default configuration lagged behind the other two.

Reloading the Monolith (Gradle Refresh)

During the Gradle refresh, the default configuration caused IDEA to crash, so its timing could not be measured. The custom configurations completed the refresh, with the big configuration being the fastest.

Final GC Check After Refresh

Running jstat -gcutil again showed that the big configuration had the shortest Full GC execution time, confirming that larger heap sizes improve responsiveness.

Conclusion

The experiment demonstrates that even modest JVM memory tweaks can dramatically improve IntelliJ IDEA performance for large codebases. While allocating more heap generally yields better results, a balance is needed to avoid excessive memory consumption. For most scenarios, setting -Xmx between 2 GB and 3 GB provides the best trade‑off. Developers are encouraged to use jstat or jvisualvm to further analyze how different JVM options affect their specific workloads.

Discussion

What idea.vmoptions settings do you use? Share any additional tips for speeding up IntelliJ IDEA.