Severe Lagging/Performance Issues in Latest IntelliJ IDEA Versions (2025.x+)

Yuriy Shatrov, users are reporting that 2025.3.2 versions fixed the lagging for them, can you confirm? Otherwise, can you try to run the IDE with 3rd party plugins disabled?

Anders Appelt Thomsen, can you share more details, we have several causes of slowness behavior reported by users in 2025.3, Islands themes or big maven projects for example. Another cause could be metal rendering on macOS, can you add this line:

 -Dsun.java2d.metal=false to Help | Edict Custom VM Options… and restart the IDE? Please share if it makes a difference for you.

Petru Basarab  Apologies for not reading this thread carefully enough. I'm actually using Rider and now realize that this is about IntelliJ.

I'm not sure if the mentioned VM setting should also have an effect in Rider, but I have added it, just to see.

Petru Basarab Unfortunately not, I keep up to the latest versions and mine is 2025.3.2.

I have also disabled all unnecessary plugins.

Petru Basarab Strangely enough, it has now helped. However, it is strange that I don't have this problem on another computer with the same settings and the same plugins, even though the Symfony plugin is activated. I also have a Shopware plugin active, which depends on the Symfony plugin.
Is it clear what exactly is causing this? Is there anything I can do about it?

Yuriy Shatrov can you also try to add  -Dsun.java2d.metal=false to Help | Edit Custom VM Options… restart the IDE and see if the slowness stays?

Alexander Pankow, from the provided thread dump, I identified a long-running read action originating from the Symfony plugin inspection path. This read action is holding the read lock and preventing the write permit from being acquired, which can lead to UI responsiveness issues.

To proceed with a deeper investigation, please submit a bug report so the responsible team can analyze the behavior in detail. You can do this directly from the IDE via:

Help | Submit a Bug Report

TL;DR:  Don't use `-Dsun.java2d.metal=false`, but do try using the “Classic” terminal engine.

I decided to try the `-Dsun.java2d.metal=false` workaround, but when I edited the idea.vmoptions file, I noticed it was already set, which reminded me that I added it a couple years ago to work around another IntelliJ performance issue and never reverted it.

I left it set to `false`, and ran the CPU profiler, and typed a bunch of stuff in the terminal using the “Reworked 2025” terminal engine. IntelliJ version 2025.3.2. Dark theme (not Island)  Here were the results:

The biggest bottleneck is rendering. The Java2D Queue Flusher is spending almost 40% of CPU time on glyph rendering and texture uploads via OGLRenderQueue.flushBuffer() and OGLTR_DrawGlyphList().

Here's the irony: even though I disabled Metal with -Dsun.java2d.metal=false, the stack traces show AppleMetalOpenGLRenderer — meaning the OpenGL calls are going through Apple's Metal compatibility/translation layer anyway. macOS deprecated OpenGL, so all OpenGL calls get translated to Metal under the hood, effectively giving me the worst of both worlds: the overhead of OpenGL plus the overhead of Apple translating it to Metal.

So…I re-enabled Metal by removing the custom VM option, and restarted IntelliJ. Good news — general performance in the editor was almost as fast as normal, and Java2D Queue Flusher dropped from 555 to 159 samples (71% reduction).

However, typing in the terminal was still slow, so I ran another CPU profile.  The Culprit: IntelliJ's Built-in Terminal

Multiple stack traces show the same pattern:

MutableTerminalOutputModelImpl.doReplaceContent
   → DocumentImpl.replaceString
     → DocumentListener.beforeDocumentChange / documentChanged
       → DaemonListeners, IdentifierHighlightingManager, FoldingModel,
         RangeMarkerTree, AsyncDocumentChangesListener, etc.

IntelliJ's new terminal implementation (2025.3.x) uses IntelliJ's document model for terminal output. This means every character you type in the terminal triggers the same document change listener machinery as editing a code file — daemon listeners, highlighting cache invalidation, folding updates, range marker updates, etc.

So I switched to using the “Classic” terminal engine, and speed when back to mostly normal.
 

Here's a cleaner and more thorough write-up of my previous post, with the help of Claude Code:

---
TL;DR: Two root causes identified via JFR profiling on macOS: (1) the OpenGL-to-Metal translation layer in Java2D is a major CPU bottleneck — re-enabling Metal direct rendering reduced Java2D Queue Flusher CPU usage by 71%; (2) the new terminal implementation in 2025.3.x uses IntelliJ's document model, causing every terminal keystroke to trigger the full document change listener pipeline (daemon listeners, range marker updates, folding model, highlighting cache invalidation, etc.) — switching to Classic terminal resolved the typing lag.                                                                                                                                                                                                 
---

 Environment: macOS (Darwin 25.2.0), IntelliJ IDEA 2025.3, Corretto JDK 21, 4GB heap (-Xmx4096m)

 Symptoms: General UI sluggishness and significant typing lag in the built-in terminal.

 Not the cause: Islands theme (not in use), AI Assistant plugin (not installed).

 Investigation:

 Issue 1: Java2D rendering pipeline

 My idea.vmoptions had -Dsun.java2d.metal=false, which forces Java2D through the OpenGL path. However, JFR profiling showed that the Java2D Queue Flusher thread was the #1 CPU consumer at 39% of all execution samples, with stack traces showing AppleMetalOpenGLRenderer — meaning OpenGL calls were being translated through Apple's Metal compatibility layer anyway (since macOS deprecated native OpenGL).

 Fix: Removed -Dsun.java2d.metal=false to let Java2D use Metal directly, eliminating the OpenGL-to-Metal translation overhead. The Java2D Queue Flusher dropped from 555 to 159 samples (71% reduction).

 Issue 2: New terminal engine document listener overhead

 After fixing the rendering pipeline, typing lag persisted specifically in the built-in terminal. A second JFR capture showed AWT-EventQueue-0 dominated at 554 samples, with stack traces revealing:

 MutableTerminalOutputModelImpl.doReplaceContent
   → DocumentImpl.replaceString
     → beforeDocumentChange / documentChanged listeners:
       - DaemonListeners
       - IdentifierHighlightingManager
       - FoldingModelImpl
       - RangeMarkerTree
       - AsyncDocumentChangesListener (external system auto-import)
       - LogicalPositionCache
       - PlatformActivityTrackerService (creating Throwable for stack traces)

 The new terminal in 2025.3.x uses IntelliJ's full document model for terminal output, so every terminal update fires the same listener machinery as editing a source file.

 Fix: Switching to Settings > Tools > Terminal > Classic terminal resolved the typing lag.
 

Petru Basarab I've created a bug report. https://youtrack.jetbrains.com/issue/WI-83995/PHPStorm-2025.3.x-constantly-freezing-Symfony-Plugin :)

Petru Basarab 

> add  -Dsun.java2d.metal=false to Help | Edit Custom VM Options… restart the IDE and see if the slowness stays?

Yes, I have done it, I will monitor for a while and report back, thanks!

I also changed the terminal to Classic though I don't usually use the built-in terminal.

Hi Petru Basarab . I am on the latest version and still finding the issue. 

1. I am observing it on only 1 project for now
2. As soon as I start typing things start to lag, or when I open file which is not so huge.
3. I was observing this in a year older version and upgraded directly to the latest one
4. It used to work fine. After installing go plugin things started breaking, now even after removing it didn't come back.
5. I am on a simple Darcula theme with only IdeaVim extension enabled.
6. I've attached the memory analysis report and the logs zip file too.
7. Apart from this I've tried disabling metal, allocating more memory(prevly it worked fine with 4G but now I've allocated it 6G, still it lags
8. I've tried allocating it 12 G too, but it still lags the really same way as soon as it is launched with that project.
9. That project's entire size is 319 M (including all, the build files too generated via `du -sh .`)
10. I've tried setting the following vm options but still it doesn't work well.

-Xmx6144m # self
-Xms2048m # via gpt
-XX:ReservedCodeCacheSize=512m # via gpt
-XX:+UseG1GC # self
-Dsun.java2d.metal=false # discussion
-Dsun.java2d.opengl=true # via claude

Machine: M4 Pro, 24G RAM, Sequoia 14.1

Please let me know what I need to do in order to get this resolved.

Upload id: 2026_02_16_xohiqnv3dzpkS7DLWsDWj2 (files: memory_report.txt, idea-logs-20260216-13201315859349630918418231.zip)

IntelliJ IDEA 2024.3.7 (Ultimate Edition)
Build #IU-243.28141.18, built on September 10, 2025
Licensed to Ayush Shrivastava
Subscription is active until August 29, 2026.
For educational use only.
Runtime version: 21.0.7+9-b631.52 aarch64 (JCEF 122.1.9)
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.lwawt.macosx.LWCToolkit
macOS 15.1
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 6144M
Cores: 14
Registry:
 ide.experimental.ui=true
Non-Bundled Plugins:
 IdeaVIM (2.22.0)
Kotlin: 243.28141.18-IJ

Hi Ayush 1901cb14, it is better if you report this in a YouTrack ticket, you can do it from the IDE (Help | Submit a Bug Report…).

Hi! 

Just reporting back, that after disabling “metal” with `-Dsun.java2d.metal=false` and switching to classical Terminal (though I have not used the built in terminal) I haven't experienced performance issues.

Also, I noticed the same issues in PyCharm and disabled “metal” there similarly, and so far running smoothly.

Hope this helps!

I am getting unbearable typing lag and overall UI lag with my M1 Macbook Pro with 32GB of RAM running Tahoe 26.2 and Intellij 25.3.2. I've never had this problem before, spanning several years.  The constant sluggishness typing and using the UI in general is extremely frustrating.

Hi Jtrimm, 

Can you try disabling metal by adding this row -Dsun.java2d.metal=false to Help | Edit Custom VM Options, and Restart the IDE.
Also, if you have an Islands theme enabled, please try to use Darkula or Light instead and see if it makes a difference.

If the above suggestions don't work for you, please open a ticket with us, you can do it directly in the IDE, Help | Submit a Bug Report…, and the responsible team will assist you. 

I'm also seeing a lot of lag, especially with multiple windows open. Switching from a custom theme to Dark was a big improvement but it's still very laggy. I'm on an M3 Mac with 36GB of memory.

I also have the lagging issues. IDEA 2025.3.3. MacBook Pro M4 PRO 48GB RAM. It is really bad when 4+ projects are open at the same time. 

As suggested i changed the theme from “Islands Dark” to “Dark”. No further changes were made. Changing the theme to “Dark” seems to fix the lagging issue completely!

EDIT: Unfortunately the lags are still present using Dark, but they occur much later

 I had the same problem on Mac and Linux and Classic UI fixed it for me. On Linux, Im using wayland.

Petru Basarab Yes. It also help to mark the `.devenv/state/mysql` directory as excluded. The database of this project is very large because it is a copy of the production system. It seems that the symfony plugin gets stuck when scanning this folder.

See here: https://youtrack.jetbrains.com/issue/WI-83995/PHPStorm-2025.3.x-constantly-freezing-Symfony-Plugin

From time to time, I encounter the same issue as Stefan Laesser GPU usage spikes to nearly 100% (as verified in Activity Monitor), and the IDE becomes unusable - every typed character is delayed significantly. This occurs regardless of which project is open at the time. A restart is the only workaround that resolves the issue.

M4 Pro, 48 Gb RAM, macOS 26.3

IntelliJ IDEA 2025.3.3
Build #IU-253.31033.145, built on February 20, 2026
Source revision: 212d61deaf3a8
Runtime version: 21.0.10+7-b1163.108 aarch64 (JCEF 137.0.17)
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Toolkit: sun.lwawt.macosx.LWCToolkit
macOS 26.3
GC: G1 Young Generation, G1 Concurrent GC, G1 Old Generation
Memory: 2048M
Cores: 14
Metal Rendering is ON

When are you going to fix that issue? I'ts been known for three months now.

Still no fix after months of issues ? Have to use old version to be able to work. Every 2025.3 updates make it unbearable to use on Ubuntu 24

Rusmacari, if you haven't tried any of the workaround described in this thread yet, can you add this row

-Dsun.java2d.metal=false to Help | Edit Custom VM Options ?

Bbisson Baptiste, We understand how frustrating this must be, especially if you’re forced to use an older version to stay productive.

That said, freezes and performance issues on Ubuntu 24 can have different underlying causes, and we’ll need specific diagnostics to understand what’s happening in your case.

Please reproduce the issue and submit a report via Help | Submit a Bug Report… so the logs are attached automatically. With that information, we can investigate your setup more precisely and provide targeted guidance.

I recently updated to 2025.3 on Ubuntu 24, after which PhpStorm became incredibly laggy. I wanted to let you know that turning off the ‘Show Project Gradient’ fixed the lag. I'm using the ‘Atom One Dark (Material)’ theme.

Petru Basarab It seems you are being dismissive. This is an obvious bug in recent versions. Are developers working on fixing this or not?

Hi Bhardwick, apologies for that. Can you confirm if you've tried to switch off metal rendering on macOS?

By adding this row -Dsun.java2d.metal=false to Help | Edit Custom VM Options

Hi Petru Basarab , I had severe performance issues since macos 26 update in phpstorm. Typing was really slow, always freezing for a few seconds and not even buffering my keys correctly. Disabling metal rendering seems to have helped in my case. (Macbook Pro M2 Max)
Did not have any freeze for over an hour now, hoping it will stay this way. Will report if something changes.

Petru Basarab tried all available workarounds, including -Dsun.java2d.metal=false, but the improvement was minimal. With five projects currently open, GPU usage rises above 50–70%.