CLion 2018.2 high CPU usage

Same problem here, also since somewhere in the end of last week. I didn't have this problem before. CLion keeps using 50% CPU even when I'm not doing anything. CLion doesn't seem to be doing anything either. I tried reinstalling but it keeps using 50%+ CPU all the time.

clang, I guess...

Hello everyone!

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 issue using CLion 2018.3 EAP, please capture a CPU snapshot and send it to clion-support at jetbrains.com so we could take a look.

I'm using CLion 2018.2 on ubuntu 18.04

I encountered this question just serveral minuties ago. The CPU go to high suddenly.

Neither reboot CLion nor reboot my computer, It didn't work!

The total difference between normal and high cpu is that I added glm(OpenGL Mathematics) which contains a lot of .hpp files to my CLion project.

After I delete glm from CLion project, the CPU come to normal !

I started to look for an alternative to QtCreactor, then I faced this issue. High CPU usage, besides CLIon is very sluggish with bigger projects.

We are sincerely sorry for the inconvenience! We are working hard on CLion performance improvements and are planning that CLion 2019.1 will contain some important fixes. Please stay tuned and follow updates in our blog.

In my case CLion 2018.3.2 is almost unusable on a high end Mac Pro (Core i7, 16gb, SSD, Xmx=8192).

This seems to be a pretty common issue in medium to large projects. What troubleshooting or mitigation steps can you provide?Are there features we can disable that are possible culprits? Would a thread dump help troubleshoot the issue?

Can you give us something more than "wait for the next release"? 

2018.3.2 is very fluid on my new setup (8600K 16Gb DDR4) with default configuration including all-levels assistance. Not as fast as a text-editor like emacs when it comes to text editing, but fast on every feature, including full completion for all my included libraries.

On my former setup (Core i7 Nehalem), 2018.2 was a real pain for such projects, but the .3 update was already a big stride and a huge relief until I could switch to my new computer. I never want to hear of .2 again.

The only thing I really still hate is macro execution. There is so much lag between commands in the recorded macro, and worst of all you have to wait for the whole sequence of actions to be fully executed because your own user actions will be inserted in the current execution stream. A better CPU helped this a little, but did not manage to have this work as smoothly as macros work in emacs.

@Sam Y, you can try increasing the Xmx JVM option according to this guide. If it doesn't help, please provide a CPU snapshot or, in case of complete freeze, automatically generated thread dumps which are located in the logs folder to clion-support at jetbrains.com so we could investigate your issues.

So, after going nuts over the performance issues I've experienced with IntelliJ and other JB products (CPU spikes, slowness everywhere), I found a solution in my case, which might help Linux and MacOS users alike:

System:
nvidia GTX1060
16 GB memory
two 4K screens
Ubuntu 18.04 [KDE] with propriatary nvidia drivers

So all issues were resolved after disabling "Force Full Composition Pipeline" in nvidia settings. After switching from Gnome to KDE, I've enabled this option to prevent screen tearing in Chrome (which was pretty bad).

As far as I know, KDE and OSX use a similar rendering pipeline, so probably you will find some hints here:
(check if modifying VSYNC/composition settings change this behaviour)
https://stackoverflow.com/questions/31793228/osx-pushing-pixels-to-screen-with-minimum-latency 

For Linux users, (in my case Ubuntu 18.04), I use taskset to limit the number of CPUs that CLion can use. Everything runs smoothly, CLion can no longer eat all my CPUs.

Edit the clion.sh file to add taskset like below. In my case I only allow CLion to use 2 CPUs.

# ---------------------------------------------------------------------
# Run the IDE.
# ---------------------------------------------------------------------
IFS="$(printf '\n\t')"
taskset 3 "$JAVA_BIN" \
-classpath "$CLASSPATH" \
${VM_OPTIONS} \
"-XX:ErrorFile=$HOME/java_error_in_CLION_%p.log" \
"-XX:HeapDumpPath=$HOME/java_error_in_CLION.hprof" \
-Didea.paths.selector=CLion2019.1 \
"-Djb.vmOptionsFile=$VM_OPTIONS_FILE" \
${IDE_PROPERTIES_PROPERTY} \
-Didea.platform.prefix=CLion \
com.intellij.idea.Main \
"$@"

More info about taskset: https://www.howtoforge.com/linux-taskset-command/

I'm back with some less optimistic news.

Currently using 2019.1, I noticed the IDE stalls and stutters a lot when I type code in the IDE. This occured after adding yet another templated library into the project, but this is what we do when we code.

The cursor is not showing, and the IDE does not respond during 1-3 secs while I type (the rest of the OS being fine). The integrated CPU meter shows nothing, but htop shows clangd processes at 100% *exactly* when the IDE stalls.

So far, I managed to disable clangd and everything is smooth again, smoother than before. I cannot yet measure how many features I lost without clangd, but I can still get the basics I need.

For the very least, typing and other basic features should *never* be stopped or slowed down by anything clang does. As I said, I have a high-end desktop CPU with 6 cores, it's more than enough for clangd to run many background tasks that will decorate my IDE or show some feedback & advice. But just let me type, do not block my typing or completion or IDE interface, and show advice only when ready. 'Nice to have' VS critical features I guess...

PS: my VM options:

# custom CLion VM options

-Xss2m
-Xms1000m
-Xmx4500m
-XX:NewSize=128m
-XX:MaxNewSize=256m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-server
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-Djdk.http.auth.tunneling.disabledSchemes=""
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow
-Dawt.useSystemAAFontSettings=lcd
-Dsun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine

With CLion 2019.1 and a high-end Macbook Pro (Core i7, 16G Ram), The fan is working every time I change a bit in a header or when I try to use the auto-complete feature. Adding one variable is enough to increase both "clangd" and "CLion" task to 196% and 120%, and the fan works as the result.

As I said in the post before, I suggest you to deactivate "clangd" in the options menu, then relaunch CLion.

The options can be found in: Preferences>Languages & Frameworks>C++>Clangd.

It's a per-project option, so you can have it off for projects which overload clangd, and have it on for those with no problems.

In my case, with the option off, I get rid of any freeze and stutter, just because the clangd processes that used to take 100% cpu disappeared. I can keep the code completion and colouring and even error notices. I just lose some advanced hints that came with 2019.1 edition, but I get lightning-fast typing & completion like I never experienced before with CLion 2018.X.

Please let me know if it works for you, because future CLion releases are supposed to rely entirely on CLangd: they need feedback to prevent future disasters IMHO.

Thanks for the hint about disabling clangd. Now everything is smoother. But still, I see CPU spikes every time I use auto-complete (like CLion CPU usage raises to 85-110% for a few seconds). Is that normal?

PS: the framework in question (cocos2d-x) is a game engine and is big.

Well, it may be expected from CLion with a huge framework. Though, I use VTK+ITK+Boost+... and it is *very* smooth now, though my framework is quite huge already.

But I have a high-end hexacore-CPU Desktop PC (Core i5 8600K, 16 Gigs), and maybe cocos2d-x pushed CLion to some of its limitations...

I confirm that I get some processes in the background while I type, including clang-tidy and other clion/.jar related processes. They show up and disappear but it's not a big deal when my CPUs are not saturated.

You may also verify that you do not run out of clion-allocated memory: there is a memory meter in the bottom-right corner. Any memory saturation (clion's or system's) will result in stutter and CPU overhead. Former posts here show how to increase memory passed to the VM.

You may decrease the inspection level if it's still too slow (the tiny 'guy-with-hat' icon close to aforementioned memory indicator), but I did not need to. My motto is: typing first, completion second, and the rest in the background. So far, it works well with my current setup, and even with a 2500K CPU & 16G DDR3. So Clion settings adapted to each clion version and code project complexity are key I guess...

Same thing here. I tried many suggestions listed above, but I'm still having the problem.
The CPU tops 100% even when I move lines up or down.

I got a I7 with 16GB RAM 

I really love Jetbrains, but this is annoying.

The 2019.2 version runs very fine here. I just gotta avoid getting out of jvm memory...

With my current project, I allocated 8 Gb to the jvm (it was only 4.5 Gb when I posted my jvm file)

Do I have to buy a Server grade processor to run this? 

Currently, I am using power saving mode to stop these background jobs.

Disabled Clangd as suggested, CLion still pushes out my 6-core MacBook Pro and my 8-core desktop to their extremes on a small-medium sized project in 2020

I faced a similar issue, and had switched over to VSC.
However I decided to try switching to power saver mode for the inspector and the performance significantly improved.
I felt that even with power saver mode on I got better code analysis compared to VSC.

This is definitely not the best solution and clarity about what exactly is hogging the CPU would be great! But I hope this helps people who really want to get CLion to work for them.

I wonder if the Static Analysis algorithm that CLion uses to find variables that are created but never used in the program has some type of bug that does not catch circular references. This is a common problem when doing Static Analysis and tracing variable usage in C++. It would definitely cause high CPU usage...

That's a good point! 

CLion also started freezing on me since recent updates on a 32gb, 6 core, 3.6ghz linux machine. I only give it 8gb but the codebase isn't very large and it used to work before fine before. 

Any news on this? 

Just started to use CLion (for WSL development). And I have exactly the same issue.

Sebastian Rosenzweig there is no universal performance problem. Quite often the root causes of such problems are different on different projects and in different scenarios. That's why we kindly ask you to capture a CPU snapshot and send it to clion-support at jetbrains.com so that we could take a look and identify what problem you are facing.

will do. thank you!