Performance and memory problems when using CLion

Assuming you have a fairly large code base in modern C++, or rely heavily on templates or macros usage, performance and memory issues during indexing and editing are possible in CLion. While we constantly work on improving CLion performance and memory usage, we recommend you check these Performance tuning tips in our web help:

To report a performance problem, please follow these instructions. To find IDE logs to attach to the problem, use this link.

 

80 comments
Comment actions Permalink

Please turn on the memory indicator in the IDE to see the real usage.
If you have "-Xmx2000m" set, then Java process won't use more than that. But there is also Clangd. It uses up to 8Gb and is automatically restarted if requires more.

So if you see 11Gb, please turn on the memory indicator in the IDE: Settings/Preferences | Appearance & Behavior | Appearance | Window Options | Show memory indicator. It will enable both indicators - for Clangd and for Java engine. Check the numbers there please.

If that's Clangd usage constantly coming to the upper limit, please contact our support – we need to investigate some Clangd logs.

Edited by Anastasia Kazakova
0
Comment actions Permalink

Rider is set to 9GB memory max, and it rockets up to that when I do a Command-T to search for a file.  A heavy GC happens bringing it down to 4GB usage and it seems to recover, then it continues to, I assume, index files/symbols further and then crashes.  It's reapeatable, and heavily frustrating.

0
Comment actions Permalink

David,

Sorry, seems this was about Rider, not CLion. Missed that. Can you please report that to our support, we'll request more details to investigate the crash? (Submit a request here please https://rider-support.jetbrains.com/hc/en-us)

Edited by Anastasia Kazakova
0
Comment actions Permalink

Anastasia, the numbers I report are from the memory indicator. It was giving me 987 out of 8000 for clangd and 98xx out of 9872M for Heap size.

CLion becomes frozen with a spinning wheel for so long that creating a dump is a pain just waiting to be able to interact with the running process. I did create one however yesterday and it should be uploaded. From what I saw there were 2 hashmaps reporting 4GB of use each! That seems excessive to me, whatever what they are used for... Unfortunately the dump upload was a bit mysterious and when I clicked on its number, it  got me to a login page under the wrong ID. From there I had lost its number. I don't know how to point you to the dump except to check for a large dump from yesterday. 

PS: I still don't understand why it picks 9872M for the heap size given the flag I have for -Xmx2000m

Edited by Michel Lesoinne
0
Comment actions Permalink

Hi Michel,

the most common cause for overridden heap size is the presence of Java-related environment variables, do you have any? Also, if you do "Help | Edit Custom VM Options" - what's written there?

As for the memory usage itself, I'm not able to find one - what's the filename should be? Also could you please try to capture it by clicking "Help | Diagnostics | Capture Memory Snapshot" when there is still 1-2GB free memory left (so we're sure it's not corrupted)?

0
Comment actions Permalink

Intelij IDEA Stable version 2019.2 currently is using 6 GB of RAM after 1hour. Developers in our team are getting annoyed that they must restart IDE a few times per day. Setup macOS Catalina and High Sierra, Java8, default properties. 

 

We have 6 professional licenses in out team, could you help us? 

Edited by Relyon Licenses
3
Comment actions Permalink

@Relyon, could you please contact the IntelliJ IDEA support team by submitting a request here: https://intellij-support.jetbrains.com/hc/en-us/?intellij-idea

0
Comment actions Permalink

This is pretty terrible. I have to restart WebStorm daily, some times a couple of times. I'm only working on one project. The telltale signs are the IDE starts to crawl and I end up getting the beachball of death.

Interestingly I am using PyCharms as well. While that thing also is a pig with memory, I have rarely hit a point where the IDE crawls/beachballs or complains about memory. My -Xmx setting for PyCharms is 1024m whereas on WebStorm it was 2048m, which I just upped to 4096m.

Sadly I just restarted Webstorm. Opening my relatively simple project, already 1.14GB is shown as consumed in Activity Monitor. Not even sure why 79 threads are even in use. 

 

0
Comment actions Permalink

>The telltale signs are the IDE starts to crawl and I end up getting the beachball of death.

 

Do you mean that the IDE runs out of memory? Please try taking memory snapshots (https://intellij-support.jetbrains.com/hc/en-us/articles/207241235-Reporting-performance-problems) when the memory usage is close to its limit and provide them along with your log folder zipped (Help > Compress Logs and Show in...)

You can enable memory indicator to see how much memory is being used: in Preferences | Appearance & Behavior | Appearance, Window options section, tick the Show memory indicator checkbox. Memory usage will be shown in the status bar, in the lower right corner of the application frame

Note that the memory snapshot can include sensitive info, so I'd suggest creating a support ticket to avoid disclosing it

0
Comment actions Permalink

Okay, I'll do so. There is definitely a leak going on. My log files are have entries such as the one I added below. At times they are numerous and close to each other temporally.

It appears the IDE runs out of memory as I got a dialog indicating I was low and gave me an option to increase the memory (which I increased to 4096). Note that was the first time I got that dialog. Other times, the IDE is too unusable. It gets stuck with the beachballs that last 10 seconds+ or don't even stop ... requiring a force quit on the app. Note that the log entry below is right before I posted the comment. If you look at the very end, you'll see logging which indicates the prompting of the low memory dialog.

Interestingly, I checked the logs files for PyCharm (I'm using 2018.2) and did a grep for "LEAK" and had no entries.

One other note. From my reset yesterday, Activity monitor reflects WebStorm now consumes 3.37GB with 94 threads active. The memory indicator cites 1258 of 3971m.

I do have a license for WebStorm and it amazes me how buggy the product is, given the price. 

2019-11-06 16:20:11,968 [358756047]  ERROR - etty.util.ResourceLeakDetector - LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 
Created at:
io.netty.buffer.PooledByteBufAllocator.newHeapBuffer(PooledByteBufAllocator.java:332)
io.netty.buffer.AbstractByteBufAllocator.heapBuffer(AbstractByteBufAllocator.java:168)
io.netty.buffer.AbstractByteBufAllocator.heapBuffer(AbstractByteBufAllocator.java:154)
org.jetbrains.jsonProtocol.OutMessage.<init>(OutMessage.kt:15)
org.jetbrains.jsonProtocol.RequestImpl.<init>(RequestImpl.kt:18)
org.jetbrains.wip.protocol.WipRequest.<init>(WipRequest.kt:5)
org.jetbrains.wip.protocol.debugger.DebuggerKt.SetBreakpointByUrl(Debugger.kt:286)
org.jetbrains.wip.protocol.debugger.DebuggerKt.SetBreakpointByUrl$default(Debugger.kt:285)
org.jetbrains.wip.WipBreakpointManagerKt$FOR_REGEXP$1.createRequestParams(WipBreakpointManager.kt:23)
org.jetbrains.wip.WipBreakpointManagerKt$FOR_REGEXP$1.createRequestParams(WipBreakpointManager.kt:21)
org.jetbrains.wip.WipBreakpointManagerKt$sendSetBreakpointRequest$1.sendRequest(WipBreakpointManager.kt:135)
org.jetbrains.wip.WipBreakpointManagerKt$sendSetBreakpointRequest$1.visitRegExp(WipBreakpointManager.kt:129)
org.jetbrains.wip.WipBreakpointManagerKt$sendSetBreakpointRequest$1.visitRegExp(WipBreakpointManager.kt:126)
org.jetbrains.debugger.ScriptRegExpBreakpointTarget.accept(ScriptRegExpBreakpointTarget.kt:21)
org.jetbrains.wip.WipBreakpointManagerKt.sendSetBreakpointRequest(WipBreakpointManager.kt:126)
org.jetbrains.wip.WipBreakpointManager.doSetBreakpoint(WipBreakpointManager.kt:52)
org.jetbrains.wip.WipBreakpointManager.doSetBreakpoint(WipBreakpointManager.kt:41)
org.jetbrains.debugger.BreakpointManagerBase.setBreakpoint(BreakpointManagerBase.kt:56)
org.jetbrains.debugger.BreakpointManager$DefaultImpls.setBreakpoint$default(BreakpointManager.kt:46)
com.intellij.javascript.debugger.JSLineBreakpointManagerBase.doSetBreakpoint(JSLineBreakpointManagerBase.kt:184)
com.intellij.javascript.debugger.JSLineBreakpointManagerBase.setBreakpoint(JSLineBreakpointManagerBase.kt:110)
com.intellij.javascript.debugger.JSLineBreakpointManagerBase.setBreakpoint$default(JSLineBreakpointManagerBase.kt:102)
com.intellij.javascript.debugger.JSLineBreakpointManagerBase.setBreakpoint(JSLineBreakpointManagerBase.kt:36)
com.intellij.javascript.debugger.JavaScriptDebugProcess$MyDebugEventListener.childVmAdded(JavaScriptDebugProcess.kt:895)
jdk.internal.reflect.GeneratedMethodAccessor196.invoke(Unknown Source)
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.base/java.lang.reflect.Method.invoke(Method.java:566)
com.intellij.util.EventDispatcher.dispatchVoidMethod(EventDispatcher.java:130)
com.intellij.util.EventDispatcher.access$000(EventDispatcher.java:24)
com.intellij.util.EventDispatcher$1.invoke(EventDispatcher.java:88)
com.sun.proxy.$Proxy129.childVmAdded(Unknown Source)
org.jetbrains.wip.WipWorkerManager.prepareWorkerForDebugging(WipWorkerManager.kt:32)
org.jetbrains.wip.WipWorkerManager.workerCreated(WipWorkerManager.kt:23)
org.jetbrains.wip.WipWorkerManager$registerWorkerEvents$1.invoke(WipWorkerManager.kt:50)
org.jetbrains.wip.WipWorkerManager$registerWorkerEvents$1.invoke(WipWorkerManager.kt:9)
org.jetbrains.jsonProtocol.EventMap.handleEvent(EventMap.kt:40)
org.jetbrains.wip.WipCommandProcessor.acceptNonSequence(WipCommandProcessor.kt:64)
org.jetbrains.wip.WipCommandProcessor.acceptNonSequence(WipCommandProcessor.kt:12)
org.jetbrains.rpc.MessageManager.processIncoming(MessageManager.kt:91)
org.jetbrains.wip.WipCommandProcessor.processIncomingJson(WipCommandProcessor.kt:71)
org.jetbrains.wip.StandaloneWipVm.textFrameReceived(StandaloneWipVm.kt:53)
com.jetbrains.debugger.wip.WipRemoteVmConnection$connectDebugger$3.textFrameReceived(WipRemoteVmConnection.kt:235)
org.jetbrains.io.webSocket.WebSocketProtocolHandler.channelRead(WebSocketProtocolHandler.kt:22)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:328)
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:302)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:352)
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1421)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:360)
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:930)
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:163)
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:697)
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:632)
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:549)
io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:511)
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:918)
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
java.base/java.lang.Thread.run(Thread.java:834) 
2019-11-06 16:21:13,214 [358817293]   INFO - .openapi.util.LowMemoryWatcher - Low memory signal received: afterGc=false 
2019-11-06 16:21:13,217 [358817296]   INFO - .openapi.util.LowMemoryWatcher - Low memory signal received: afterGc=true 
2019-11-06 16:21:13,235 [358817314]   INFO - tellij.openapi.util.IconLoader - replace '/general/balloonWarning.svg' with '/icons/general/balloonWarning.svg' 
2019-11-06 16:21:13,242 [358817321]   INFO - tellij.openapi.util.IconLoader - replace '/ide/notification/expand.svg' with '/icons/ide/notification/expand.svg' 
2019-11-06 16:21:20,291 [358824370]   INFO - .openapi.util.LowMemoryWatcher - Low memory signal received: afterGc=false 
2019-11-06 16:21:20,293 [358824372]   INFO - .openapi.util.LowMemoryWatcher - Low memory signal received: afterGc=true 
2019-11-06 16:21:21,400 [358825479]   INFO - pi.util.registry.RegistryValue - Registry value 'ide.mac.allowDarkWindowDecorations' has changed to 'true' 
2019-11-06 16:21:21,432 [358825511]   INFO - tellij.openapi.util.IconLoader - replace '/general/warning.svg' with '/icons/general/warning.svg' 
2019-11-06 16:21:42,113 [358846192]   WARN - .impl.LineStatusTrackerManager - Tracker for is being held on dispose by com.intellij.openapi.editor.impl.EditorImpl@5a01e6bd; file: / 
0
Comment actions Permalink

looks similar to https://youtrack.jetbrains.com/issue/WEB-41324 that is fixed in 2019.3; if the issue persists in the most recent EAP, please create a support ticket, providing files I've asked for

0
Comment actions Permalink

Thank you, I have just downloaded it and will see how it fares.

0
Comment actions Permalink

Same issue with phpstorm - constantly using more memory until it becomes too slow I have to restart the IDE. It constantly endup using swap when I have more than enough RAM available. 

That's a serious issue for productivity and I'm seriously considering joining those switching to another IDE even after several years using phpstorm loyally 

1
Comment actions Permalink

I'm having issues as well, with CLion. It's just been terribly slow lately (currently running 2019.3.2).

I've noticed it really well when I tried to do a regex search on my entire project. IDE unusable for close to a minute.

0
Comment actions Permalink

Same here, version intellij Idea 2019.3, just opening the project and indexing.. then boom: out of memory error popup (despite -Xmx set to 3Gb!).

Switching to Eclipse.

0
Comment actions Permalink

I've added memory to my machine. I now give CLion over 30 GB of memory, and though it doesn't fill it up all the way (only up to like 60% or so) it's still at times incredibly slow for even simple things like "go to implementation"

0
Comment actions Permalink

WebStorm (v2.19.3.3) consumes 4.27GB and works very slow for me too:

 

Edited by Artem
0
Comment actions Permalink

Having the same problems with Idea 2019.3.4. Yesterday everything was still ok. Today it started with "Build Project" to display some errors spreaded over different Java-Files but as I opened the files one after another everything was ok. When I wanted to start the application, a build was done again, and again: errors in the same files.

 

I reinstalled the whole IDE and even deleted all old settings and deleted all ".idea" folders in my projects but still. "There is not enough memory to perform the requested operation."

 

I deleted the whole maven repo (was around 15GB already) but still: IDEA breaks down shortly after starting it and opening my main project. Sadly, the "Analyze Memory Usage" button does nothing.

0
Comment actions Permalink

Using CLion 2019.3.5 and I'm getting very bad performance on a 100 lines of code in a brand new project that doesn't include any external libraries.  What is going on here??  Every 10 to 30 seconds, it freezes as I type code, this is unusable.  This is not a matter of "twiddling some memory settings or cpu settings".  I don't see how that will work, I've got 16GB of RAM and running on a Ryzen CPU with lots of cores.  This is just a huge bug.

I'm actually evaluating CLion as a replacement for Qt.  I've got Qt IDE running with no issues at all on the same code.  From the looks of historical reports on this issue, it seems to be around a long time and keeps popping up somewhere. 

I really really like the CLion IDE over Qt, but....I just can't do it with a performance problem like this.

Please, any actual solutions that work?  You want me to send logs, do a memory dump of my entire system, tell me what you want and where to send it.

 

0
Comment actions Permalink

When a freeze happens, thread dumps are automatically generated. They are located in the directory with logs (Help | Show log in the file browser). Please collect the logs and share with our support at clion-support at jetbrains.com

0
Comment actions Permalink

** Work Around **

I've been investigating this issue for a few hours with Visual VM.

I was seeing a tremendous spike and obvious memory leak with Java 11 version that Jetbrains is using. The graph above is showing garbage collections but every increasing memory usage.

The Specs are this

PID: 66319
Host: localhost
Main class: <unknown>
Arguments: <none>

JVM: OpenJDK 64-Bit Server VM (11.0.6+8-b765.40, mixed mode)
Java: version 11.0.6, vendor JetBrains s.r.o
Java Home: /Users/xxxx/Library/Application Support/JetBrains/Toolbox/apps/CLion/ch-0/201.7223.86/CLion.app/Contents/jbr/Contents/Home
JVM Flags: <none>

It boils down java.util.zip.Zipfile$Source#17

I disabled all the Version control systems plugins and the spike went away and the memory now bounces around 150MB like it's suppose to.

It seems to have to do with this:

https://stackoverflow.com/questions/60835946/why-is-java11-keeping-java-util-zip-zipfilesource-on-heap

 

1
Comment actions Permalink

I let CLion run over night and it's working fine now without any memory leaks still at 139 MB.  So it is specifically the git plugin module that is leaking memory.

 

0
Comment actions Permalink

Incredibly helpful to know where the problem lies, but doesn't do me much good, since the built-in Git functionality is one of the main reasons why I use JetBrains products :(

0
Comment actions Permalink

I just updated IntelliJ to 2020.1.1 via the Toolbox and now experiencing this weird memory behaviour.

I also can't seem to find the Memory Indicator option where it is described to be or anywhere via searching.

Please advise?

Update: Found it; need to right-click on the status bar and enable it

https://www.jetbrains.com/help/idea/increasing-memory-heap.html

Still weird memory leak though

Edited by Darren Bishop
0
Comment actions Permalink

just updated to Pycharm Community Edition 2020.1.1, having the same memory issues, but it seams to go away after indexing is done(which takes 1-2 hours!!) 

0
Comment actions Permalink

Klhurley's didn't seem to work at the beginning but after a while Pycharm started flushing memory and now it works as expected. Thanks!

EDIT: after changes in git from the terminal, the problem reappears...

EDIT2: it's the CSV plugin! Go to File | Settings | Plugins and disable it. I did this two days ago and had no more problems.

Edited by Eudald
0
Comment actions Permalink

I had this problem after upgrading to 2020.1.1, and disabling git and other VCS plugins did not work for me. What did work was disabling CSV Plugin, as suggested in this other issue: https://youtrack.jetbrains.com/issue/IDEA-240557.

2
Comment actions Permalink

Its the CSV plug in for me don't install that plug in!!!!!

1
Comment actions Permalink

I think it's not the CSV plugin for me.
Disabling all unnecessary plugins was one of the first things I did iirc, but I'd have to check that.

0
Comment actions Permalink

THANK YOU!

 

Its incredible, but the CSV plugin was taking all my 32GB of RAM. Disabling it fixed it.

2

Please sign in to leave a comment.

Have more questions?

Submit a request