CLion is very, very slow


I am running CLion on a Ubuntu Linux machine and a MacOS machine.  Most of my work is on the Ubuntu machine.   Here are the issues I have:

- Opening a file is slow.  It can take 3-10 seconds to open a file.  This is on both Linux and MacOS, and the files are modest size (say 1500 lines).

- I've become very familiar with the pop-up: "Resolve operation requires more time" as it occurs frequentyl, and sits on my screen for minutes at a time.

- CLion generates multiple "threadDumps-freeze" logs per day. (Linux)

- For a while I was working with 4G of virtual memory space, and I would often site at 3.5G when doing complex operations.  I upped the VM to 8G, and now CLion idles with VM at 4-6G.   

How should I proceed?



Please send automatically generated thread dumps (those "threadDumps-freeze" files) which are located in the logs folder to clion-support at so we could investigate your issues.


I have the same, sometimes this pops up:

"Resolve operation requires more time"

, but more importantly, *every* time an autocomplete would be useful, e.g. when appending characters to already typed names:


typedef int MyType;

typedef const int MyTypeConst;

MyType foo;


and then going in and changing the type of foo from MyType to MyTypeConst, when you press "C" it hangs for seconds...

Annoyingly, going into Power Saver Mode does not help...


CLion on OSX

Build CL-182.4323.58

JRE: 1.8.0_152-release-1248-b8 x86_64

JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o 



I have the same issue on OSX


Hi, @Aron, @B Gaifullin

Please try using CLion 2018.3 EAP which contains some performance improvements. Please note that you don't need to uninstall the stable version in order to test the EAP build - they can be installed side-by-side.

If you still face the issues using CLion 2018.3 EAP, please send a captured CPU snapshot or automatically generated thread dumps (those "threadDumps-freeze" files in the logs folder) to clion-support at so we could investigate your issues.


The version  CLion 2018.3 EAP is much better, but the pop-up "Resolve operation requires more time" appears again.


Has this ever been solved? It's still a problem for me. It's so bad, I'm using cerr instead of the debugger. Is it possible to revert back to a previous release? I think this all started in 2018.2.x

I've tried deleting the cmake-build-debug directory and rebuilding it.

I've tried hard booting

I've tried 2018.2.5 EAP

I've tried 2018.3 EAP

All with no luck. Message appears briefly from inspector. Appears and never goes away during debugging when inspecting Eigen Vector4d variables in the tree. If I press Cancel button soon, it comes back. If I let it sit 10 minutes, the mouse moves but no response from CLion or MacOS. Smells like stack overflow.

MacOS High Sierra 10.13.6 i7 16GB



@PRyan, please try this workaround. If it doesn't help, please send a captured CPU snapshot or automatically generated thread dumps (those "threadDumps-freeze" files in the logs folder) to clion-support at so we could investigate your issues.


I'm going through the same ordeal with a project that uses Eigen in2018.2.1, 2018.2.5 and 2018.3 EAP.

I've already made a separate issue and posted the snapshot and the thread dumps, and @Anna Filippova has kindly posted some of the bug tickets here:

Linking here because this seems to be a popular thread that comes up in Google Search.

If you're suffering from this, please upvote these:


I've been using CLion 2018.3 EAP for a while.   I haven't noticed any improvement.

One problem I've seen is that the VM usages is even higher.   Where it used to idle around 4G, it now idles around 6G. 

I have lots of threadDumps-freeze I can send. 


Peter, feel free to send them to clion-support at


I am experiencing same problems with CCion 2018.3. I've increased heap space to 5500 MB but it does not help.

I am using the CLion with the Monero project, which has quite big codebase ( )

But still, rename refactoring takes way too long. Even waiting for a red rectangle to appear is too long. And changing the name is very sluggish as it automatically tries to replace all occurrences on each key stroke. I would rather accept not real time refactoring, but smooth name change and then refactoring all occurrences.

This sluggishness makes me really unproductive. 



My issues on a project that is using Eigen haven't at all been resolved with the release of 2018.3. Issuing the "Show Intention Actions" on any function takes upwards of half a minute on a very fast machine (heap space adjusted). Likewise for code completion, refactoring, and automatic code generation tasks.

For those who are also still struggling with these issues:

Eclipse CDT with the cmake4eclipse and CMakeEd plugins is now a more viable alternative for CLion on C++ projects using Eigen. It has it's own faults, and initial configuration might take awhile until the pistons are pumping, but at least it doesn't constantly freeze up like CLion does, and offers reasonable on-demand code-completion, function/variable/class name refactoring and code navigation, as well as built-in git support and an in-IDE terminal. It doesn't offer method signature refactoring or code generation (sorely missed), but it's a reasonable temporary (and free) compromise.

Personally, I've opted to use Eclipse CDT until performance issues with CLion are fixed. I'll be checking back on CLion periodically.


I have the same issue. Each action which involves "Eigen3" is quite slow. Jetbrains please put more effort in supporting the widely used Eigen3 library!


Same issue here with the Eigen3 library. Note that the IDE is slow even on symbols that do not involve Eigen.


Same issue with Clion 1:2018.3.2-1 running on Manjaro linux kernel 4.17.19-1 using the Eigen3, Boost 1.68 (units library) and Project Chrono. I Changed the vmoptions -Xms2048 and -Xms4096 . Resolve takes forever and seems to use 1 CPU (8 available Intel i7) memory use 1.4GiB (16 GiB available) Disk write ~68 kiB/s running of a sata SSD disk. Each time the resolve operation popus up I'm forced to close Clion because it becomes unresponsive or I have the wait for ~5 till 10 minutes.


Same issue as above with clion-eap-183.4886.39-1


Same issue as above. The "Resolve operation requires more time" will stay up for minutes. This is crippling my productivity. Getting the same problem on 2018.3.1. 


Everyone, I've opened a performance issue on YouTrack about this:
Please upvote.


CLion continues with being slower and slower after each official release.

The Ctrl+click navigation on the same project, on the same hardware, continues to increase after each new release...



I am using the latest version. I feel like the resolve operation of code navigation is the slowest of the last two years and just keeps getting slower with every version. Details of version below:


CLion 2020.1.1
Build #CL-201.7223.86, built on April 29, 2020
Runtime version: 11.0.4+10-b520.11 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.15.0-99-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 3987M
Cores: 8
Registry: run.processes.with.pty=TRUE,

Current Desktop: GNOME



Faced with the same issue. CLion 2021.1 very very slow for me with each new release. It is faster with an M1 processor on MacBook 16GB. But other IDE compared to this, just fighters.

1) I'm using the "Juce" framework. and on intel processor: Generate definition for function 'void test();' appears only after 15-30 sec. i.e. I'm waiting for the orange highlight. Then clicking generate, takes for me 1-2 min.

2) On M1 orange highlight appears after 1-4 sec. And clicking on "Generate definition" can take 1-20 sec.

3) File scrolling is simply a step game, with no smooth. It also actually can freeze any time for 1-10 sec. Code scrolling is faster but again it should be much much smoother like in the QT or XCode, VSCode, etc. I feel like it has 7-12 fps.

Any reason why it so slow? I have only opened CLion in the system. Nothing more. And the CPU load is about only 4% - 7.7% My app contains only about 20 small files now + Juce headers


The same here. Since 2018, CLion keeps getting slower and slower on my MacBook.. Now, in the version 2021.1 on a simple project with a refactoring kata, it takes ~3-4 minutes to do a simple 'extract function' refactoring which worked instantly in 2016/2017. 


Please sign in to leave a comment.