This statement is false. It's way too broad a claim to hold up. With all due respect I'd consider it harmfully incorrect.
Counterexample: I use CLion to work on Cataclysm: Dark Days Ahead. It's ~360,000 lines of pretty hairy C++. It's fine.
There may be conditions that make a stricter definition of the claim true. I don't know what those conditions would be. A link to Jetbrains' definition of the issue would be good.
Obviously there are (many) reasons for that. What you think is hairy might not be that hairy, in terms of parsing, to a compiler or static analyzer. If you're like most game developers, you use a simple subset of C++ that's C-like, which might explain why you're lucky.
Maybe the word 'tiny' was excessive. It might not affect someone's homework, but in my case it definitely does have performance issues for my relatively small one-man projects. I'm not bashing the tool; I'm a paying user too. But no one can deny the many performance issues, and indeed the focus of the next major release is precisely to start addressing those.
I also used AppCode extensively, that one actually behaved pretty well, overall.
So I am not really surprised by CLion's performance/stability issues. I have a long love/hate type thing around this with Jetbrains.
I hope they can get these things sorted out.
I often wonder if they wouldn't be better rewriting in a non-GC'd language. Rust or something.
It's a question of for-all-x vs. there-exists-x. I acknowledge that there exist x'es that are small projects that make CLion hang.
I just wanted to make sure it was known that it's not all x'es. And that there exist y's that are large projects that don't hang. Cataclysm DDA is not a simple codebase :)
I've run into this issue, also. It's not Visual Studio levels of constant freezing, but it definitely pauses once in a while. Seems to mostly occur when I'm developing on Windows, though.
EDIT: Wanted to add that it's definitely a regression. I've been using CLion without the pauses for years.