How Adjusting IntelliJ IDEA Memory Settings Boosts IDE Performance

Goal

The author aims to test four different memory configurations of IntelliJ IDEA in a realistic development scenario (loading a large project, two micro‑services, and refreshing after a git pull) and identify the setting that offers the best balance of memory consumption and speed.

Test Machine and Project

MacBook Pro Retina, 2.3 GHz Intel Core i7, 16 GB DDR3, SSD, OS X Yosemite

Project

Large monolith: ~700 k lines of Java 8/Groovy code, 303 Gradle modules

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

Test Scenario

Close all projects in IDEA

Apply settings via

idea.vmoptions

Reboot the computer

Close unrelated processes after startup

Open IDEA (measure time)

Open the large project (measure time)

Run

jstat -gcutil

Open the two micro‑service projects (measure time)

Run

jstat -gcutil

Return to the large project and click “Refresh Gradle Project” (measure time)

Run

jstat -gcutil

jstat -gcutil

jstat is a JDK tool that provides real‑time monitoring of JVM resources, including heap size and garbage‑collection statistics. The options used here are:

<code>-gcutil - Summary of garbage collection statistics.
S0: Survivor space 0 utilization (% of current capacity)
S1: Survivor space 1 utilization (% of current capacity)
E: Eden space utilization (% of current capacity)
O: Old space utilization (% of current capacity)
M: Metaspace utilization (% of current capacity)
CCS: Compressed class space utilization (%)
YGC: Number of young generation GC events
YGCT: Young generation GC time
FGC: Number of full GC events
FGCT: Full GC time
GCT: Total GC time</code>

Sample output:

<code>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</code>

The key parameters for this article are the number of GC events (YGC, FGC) and their collection times (YGCT, FGCT).

Test Settings

Four configurations were defined:

Default (gray)

<code>-Xms128m
-Xmx750m
-XX:MaxPermSize=350m
-XX:ReservedCodeCacheSize=240m
-XX:+UseCompressedOops</code>

Big (red)

<code>-Xms1024m
-Xmx4096m
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops</code>

Balanced (blue)

<code>-Xms2g
-Xmx2g
-XX:ReservedCodeCacheSize=1024m
-XX:+UseCompressedOops</code>

Sophisticated (orange)

<code>-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</code>

These settings were placed in

~/Library/Preferences/IntelliJIdea15/idea.vmoptions

(path varies by OS).

Results

IDE Startup Time

Startup time was consistent at about 10 seconds across all configurations, indicating that memory settings do not affect the early launch phase.

Loading the Large Project

The monolith took roughly three times longer with the default configuration compared to the other three settings, showing that a larger codebase benefits from more memory.

With the default setting, GC was extremely busy: both the total GC time and the average Full GC duration were dramatically higher (up to 50×), which explained the slower responsiveness.

Opening Two Micro‑services

The sophisticated configuration performed best, while the default lagged behind the other two.

jstat –gcutil After Opening All Three Projects

All three custom settings behaved similarly, while the default configuration performed poorly.

Final Reload of the Monolith

The default (gray) bar was extremely high because IDEA crashed during the refresh, confirming that the default memory allocation was insufficient.

Among the three custom configurations, the “Big” setting yielded the shortest times, demonstrating that larger Xmx values improve responsiveness.

Last jstat –gcutil Run

The differences were minor, but the “Big” configuration achieved the fastest Full GC execution time, and a larger Xmx clearly helped overall responsiveness.

Conclusion

The brief experiment shows that even modest tuning of IntelliJ IDEA’s memory settings can significantly improve IDE performance. Generally, setting Xmx between 2 GB and 3 GB offers the best trade‑off for large Java projects, though developers should balance performance gains against overall system memory usage.