Not useable with bigger projects (solved)

Answered

EDIT: The statement below is not valid for up-to-date Clion releases. Therefore this topic is solved and you should maybe open a new thread / report with specific problems.

Sorry to say - I just canceled my subscription after having terrible performance in the last weeks with bigger projects / and libraries in development.

It should be nothing new to you as the support channels are full of the same description:

1. Building symbols slow - about 10-30 mins. Only for as long as the CMakeFile is not changed as there is caching. Great but still my employer would be unwilling for me to spend up for an hour waiting for an application to open text files. I can not foresee that any of the refactoring functionality can make up for the lost time. Well if it did I'd live with it, but Eclipse offers similar functionality (at least in base tasks) and does not suffer from these interruptions.

2. Endless CPU bursts at 100% for several minutes, basically for every new file I'm opening or symbol I'm touching. And this time it seem not to cache that much. It happens over and over. Also if this was a background thing, ok but it literally freezes clion ever other click up to a point where nothing draws for 5 minutes. This game repeats itself longer than any human being has patience. This is not a background task anymore, and it makes any development impossible.

Memory usage is not even its peak. Yes, I tried adjusting the heap via VMOPTIONS. Also I disabled Reflow and set the inspection level down. Even Power safe mode. Still it is not noticeably better. Ok let's be extreme: Power saving mode, Slider to None, all C++ inspections of. Freeze. Really?

If I disable all functionality I can pretty much just use vim right away and safe the money. I haven't figured a sane setting yet.

To be fair: In smaller, home projects with minimal dependencies Clion performs pretty well. And when it rolls it rocks. It is just not worth its money in my personal opinion, yet.

I look forward to be proved wrong in future versions: Here is a benchmark for you. Download Pixar's OpenSource project USD. Build the couple of requirements (lastest Fedora has most of it). Anyone can test this for her/himself.

At the point where I can develop in this library or similar without these interruptions you will have me back as a customer. Meanwhile happy optimizing.

Cheers.

22 comments
Comment actions Permalink

Just some additional information:

Tested environments:

CentOS 7.2, Fedora 24, 25

All with pretty decent 8-12 core Xeon or i7 CPUs.

32-64 Gig RAM, tried VMOPTIONS set to default, 8 Gig, 16 Gig. No noticeable change.

Tried different java runtimes as well, up to the latest. No luck.

GPU if that should matter is Quadro M4000 or Geforce 1070.

3
Comment actions Permalink

Yea as much as I LOVE the clion ide I've had similar problems.  It is a hog when it comes to performance.  I have a very beefy system with an I7-5820 overclocked and auto complete of symbols can crawl at times, being so slow I just type it out or if I can't remember it, look it up, then type it out.

I think the problem is being coded in Java.  Java just isn't a fast language.  When I use slickedit (my other preferred IDE), it is amazing the speed difference.  I've come to love clion though so it's really sad when I hit these performance issues because using slickedit just isn't as nice.

I wish they would rework the code parsing engine in C++ at least.  They definitely have the C++ knowledge at JetBrains since their handling/parsing of it is awesome, they just need to assign that guy to their engine for a while. ;)

If it matters this is in Linux.. I have heard similar reports from OSX users but don't know any windows users to compare.

3
Comment actions Permalink

I'm using Clion on Mac and Linux almost since the day it was first released but nowadays I'm one step away from leaving it because of the same problems mentioned above. Ok, I've a very big project and I understand the burden of doing lots of code analysis. Yet it is getting harder and harder everyday/every release with Clion to keep up working properly. IDE shall help developer to go faster but nowadays I'm spending more time on my ide to develop my code.

3
Comment actions Permalink

I have to agree. I love CLion's functionality, but on my macbook pro, I get serious freezes, and the fans are usually spinning at full bore. I am close to just living with qt creator's flaws and dumping CLion. If the performance story doesn't improve, I doubt that I will renew my subscription.

1
Comment actions Permalink

I'd like to add my voice to the comments above.

CLion is just a pain on bigger code bases - it will intermittently hang, sometime without apparent cause (ie no mouse click, no keyboard shortcut other than typing etc).

I've logged an issue on YouTrack and I am only one of many. I received no updates.

Perhaps it is impossible to have a JavaVM performant enough to handle the intricacies of parsing and maintaining an internal model of a C/C++ project,but I think that the issues are not related to this since the cases when I can see the hanging, there's plenty of memory left (I've allocated 8G and only 4G are used according to the indicator) and the CPUs are not all maxed out (I'm on a shared dev box so it's rather beefy) but who knows?

What bothers me is that there is no public official acknowledgement of this - this is very different from my experience with Intellij IDEA, which I've been using since 2002 (this is not a typo). Although there are instructions on how to collect CPU/memory dumps, I see no follow up on the issues themselves.

Jetbrains used to be proud of using the phrase 'eat your own dog food' and the result was a set of tools second to none in my opinion, but
not in this case.

For tools that are supposed to aid our productivity, these freezes are a serious setback.

Just my 2c.

 

1
Comment actions Permalink

To be fair I would like to add the following statement:

Many of the described issues (in the original post) went away with the 2017.1 update.

That means that I am now able to work with big code bases, the symbols build in finite time and to not rebuild constantly.

I still have had eventual total freezes every now and then on specific actions, but it was much more controlled and I was able to work around it. It will be much easier to report the remaining issues as they are reproducible by specific actions and not by general work/typing.

I would recommend users in this thread to give it a try and report back if they haven't already tried the new version.

I am not sure if this is related to the zero latency typing feature or work on this specific issue but jetbrains has been busy to address the issue.

This leaves me with much more confidence towards a better future of the product. Thank you.

1
Comment actions Permalink

@Dariusz, @Blazej Floch thank you for the updates!

1
Comment actions Permalink

I'm running 2017.1 now.  So far it feels quite a bit faster (with the no latency typing thing).  I type 115 wpm or so, when coding I burst up to 160, so CLion has never kept up with me at all, lol.  It does a lot better now.

I've only been working on my smaller projects lately though so I haven't tested to see if it fixed the larger project issues.  All in all it seems much better/faster now though.  That could change on my next big project though.  I'll post back if it does.

It's still roughly about 25% as fast as slickedit though.  But that is just the difference between something written in C++ and something written in Java.  I still prefer CLion's features though and use it whenever I can.

0
Comment actions Permalink

@Blazej, I am running a very recent build of CLion:

CLion 2017.1.1
Build #CL-171.4073.41, built on April 12, 2017
Licensed to Bonny Rais
Subscription is active ---
JRE: 1.8.0_112-release-736-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 2.6.32-504.3.3.el6.x86_64

 

These issues are happening still, not all of these occurrences are captured by the freeze logs that are created when
CLion itself detects that it's not responsive, but I still see a couple today

threadDumps-freeze-20170419-173038-CL-171.4073.41-8sec
threadDumps-freeze-20170419-192146-CL-171.4073.41-5sec

These don't seem long, but then I was not using the tool heavily. Here are a couple from a couple of days ago:

 

threadDumps-freeze-20170414-153018-CL-171.4073.41-73sec
threadDumps-freeze-20170414-153137-CL-171.4073.41-142sec
threadDumps-freeze-20170414-162920-CL-171.4073.41-12sec
threadDumps-freeze-20170414-162944-CL-171.4073.41-16sec
threadDumps-freeze-20170414-163350-CL-171.4073.41-266sec
threadDumps-freeze-20170414-163831-CL-171.4073.41-244sec
threadDumps-freeze-20170414-173500-CL-171.4073.41-8sec
threadDumps-freeze-20170414-201403-CL-171.4073.41-7sec
threadDumps-freeze-20170414-201415-CL-171.4073.41-6sec

 

As you can see from the timestamps they are close enough to together to be really annoying.

The potential is immense, and I am still using the tool, but I cannot recommend its use to anyone yet
other than in an exploratory manner with smaller projects

 

0
Comment actions Permalink

Has there been any progress on this? This is still happening a lot to me, and I feel that whatever is causing it should be relegated to a background process. 

It makes CLion quite unusable for even slightly large projects. For example, it seems including boost and pcl at the same time (two very large libraries) causes CLion to hang. 

0
Comment actions Permalink

Can't work because if this. Have you ever tried to fix memory issues in pycharm?

I have to work always in Power Save Mode, so I am just paying money for simple text editor because on power save mode many features are disabled.

I have Linux Mint 18.3 Cinammon 64-bit, Intel Core i7-7700K CPU 4.20GHz x 4 and 16GB RAM.

Sorry but I won't resubscribe if performance in pycharm won't be fixed.

0
Comment actions Permalink

Hello everyone!

Performance problems may be caused by insufficient amount of memory. To speed up the processing you can try enabling memory indicator (`File | Settings | Appearance & Behavior | Appearance | Show memory indicator`) and keep an eye on it for some time (the indicator will appear in the bottom right corner of the CLion window). If it is close to the limit at the time when you are experiencing the problems, then try increasing the Xmx JVM option according to this guide.

If it doesn't help, we will be very grateful to you if you provide us with some additional information so that we could figure out where the problem is in your case: a CPU snapshot if you manage to capture it or, in case of complete freeze, automatically generated thread dumps which are located in the logs folder. Please send them to clion-support at jetbrains.com.

@Piotr, I assume the PyCharm team also might need some materials for investigation. Please submit a request using this form.

0
Comment actions Permalink

I've already increased memory, but it always wants more and it's using all available memory I am giving to it with Xmx JVM.

Sorry I don't have time for submitting requests.

0
Comment actions Permalink

+1 from me too. Its super awesome ide but the lags are insane! All the IDE speedup that clion offers goes away when I start getting min+ lags. I run x64win10pro 2990wx & 64gb ram. Clion is set for 40gb ram usage. 

0
Comment actions Permalink

@Dariusz, sorry for the inconvenience. If you want the problem to be investigated, please provide additional information described in my previous comment to clion-support at jetbrains.com. Thanks.

0
Comment actions Permalink

Hey @Anna Falevskaya super slow reply I know heh :- ) but anyway, I figured out the slowdown, Because I had cmake-build-debug clion/msvc/qtcreator in 1 folder/subfolders, they all got marked as "part of project" and I did not know I have to select & Exclude from project them. So as you can imagine, compiling & clion re-indexig everything was super... "fun"... anyway now I know whats up so I can exclude all that crap. Clion behaves a lot faster now and has very few "hiccups", sometimes copy/paste in to h. files can be slow... else is awesome. Thanks for awesome tooL!

0
Comment actions Permalink

Just added a note on the original statement, since it seems unfair if people come here and don't see the date.

Thanks and keep it up.

0
Comment actions Permalink

Why does it marked as solved? Clion is still very very slow on a large codebase. Indexing all the files takes ages and consumes all the memory available for JVM. I have a mid-core overclocked CPU, SSD and mid-core RAM and still have to wait a long time. I guess performance-critical components should be rewritten in C++ itself to improve performance and java side can just call those jobs via JNI. I will definitely boost CLion

0
Comment actions Permalink

It is really slow on a UE5 project. And the point is not only in indexing. Indexing just takes a lot of time, but the overall interaction with IDE became laggy, I have to wait one or two minute on such actions as a click on a line of code, comment/uncomment line, etc..
I did a CPU profiling, gonna check what's inside

0
Comment actions Permalink

I just called `Generate Overrides` action which doesn't create overrides immediately, only collects info about virtual functions of the given type and CLion hanged for a couple of minutes

 
 
0
Comment actions Permalink

I've sent an email on community-support@jetbrains.com with a subject "CLion profiling results". There is a zip file with multple profiling results i did recently

0

Please sign in to leave a comment.