CLion performance
I am growing tired of CLion's performance and want to give this one more go before I cancel my subscription before my next renewal cycle.
Just pressing enter and backspace repeatedly in a 1000-line C source file results in 400% cpu usage and loud fan noise. I'm not even saving the file. Even scrolling up and down the file has visible lag. There are many more performance issues, but not worth pointing out. Something is horribly broken. Working on a large code base like LLVM is an easy way to reproduce these issues, but they are apparent even with small files. This is not specific to the latest version either, but has been an issue for many years.
I have disabled all unnecessary plugins, experimented with low power mode, increased heap sizes, etc. The latter is also an implementation detail and I shouldn't be bothered with that as a user. Please don't link to your performance tuning guide because I have read that many times. I would like real solutions, or at least an understanding of where the problems are. This performs worse than a web application. Is there anything that can be done to improve performance? Or is this the best a Java application can do?
Thank you.
请先登录再写评论。
Hi 3gg,
We apologize for any performance issues you may be experiencing with CLion. We understand how frustrating this can be, and we want to help resolve the issue so you can have a smoother experience. Our team is continually working to improve CLion's performance, and we would greatly appreciate your assistance in troubleshooting the issue.
To identify the specific issues you're facing, we'll need some diagnostic information from you. The thing is that even in the same project (for example, the LLVM project), the issues may or may not mannifest itself depending on the setup, environment, etc. So, to find out what exactly is happening in your case, we kindly ask you to capture CPU snapshots while reproducing the issue and send them to clion-support at jetbrains.com along with the link to this thread:
Thank you in advance!
Email sent, thanks.
Regarding: https://intellij-support.jetbrains.com/hc/en-us/requests/8779042
I don't have time to run these experiments. The problems are obvious enough that your developers should be able to reproduce them. I assume your developers use CLion?
But in any case, you already identified the problem per your comment on the other thread:
This is exactly my experience, and re-analyzing on every keystroke is unnecessary and extremely resource consuming. It would be better to do this on file save, or at least expose a setting to let the user decide. There is currently a setting to turn off the analysis altogether, which isn't helpful. If you want a performance baseline, Emacs + LSP gets this right (but I still prefer CLion for other reasons, that's why I'm here…)
To further elaborate on my original post: the problem occurs specifically with large files, not necessarily large projects. As a repro case, you can open Remotery in CLion, and specifically this file: https://github.com/Celtoys/Remotery/blob/main/lib/Remotery.c Then start typing randomly; in a comment, hitting enter to add new lines, etc. Ideally on a computer with fans.
Hi @3gg,
All IDEs reparse the file as you type, not on save — your Emacs + LSP baseline included (it analyzes on change too, just debounced). And reparsing is needed for everything: completion, highlighting, parameter hints and quick-fixes all depend on it. We don't yet know which feature is actually expensive in your case, but deferring all of them to "on save" isn't an option — it would break everything that has to stay in sync with what you're typing. So the thing to fix is the cost, not whether analysis runs.
The repro is useful though, thanks. We'll profile Remotery.c and check which features are heavy on large files.
3gg, a small addition to the developer's response above:
I've created CPP-50830 to track our investigation of CPU usage with
Remotery.c. Feel free to comment or upvote it to get updates. See the YouTrack notification article if you are not familiar with YouTrack.