CLion refactorings & code/symbol navigation unusably slow on macOS version, not on Linux version, for same project
Hi,
I'm using CLion to develop a cross-platform application on macOS and Linux, it's a relatively small code base that is shared for both platforms, it only has a few dependencies on OSS libraries, and it links against Vulkan on Linux or MoltenVK on macOS. Otherwise there's nothing platform-specific in either the CMakeLists or the code itself.
CLion performance for any interaction that depends on source code analysis for this project is absolutely terrible on macOS, on a brand-new M3 MBP, while it is perfectly fine on Linux on a lower-end system. With ‘absolutely terrible’ I mean ‘near unusable’. Operations like finding related symbols (switching header/source) will take up to a minute to complete or simply hang the IDE until I kill it. Refactorings like renaming symbols is pretty much impossible for many files. Even navigating between symbols will in some cases stall the IDE for multiple seconds at a time. I have the JVM heap set to 16GB and looking at activity monitor CLion hardly stresses 1 core of the CPU for these slow/hanging operations.
As said, CLion on Linux is absolutely fine for this project, while both systems are using the same version (2023.3.2, but this performance problem was already there for at least ~1 year since I started working on this project), so it seems something is broken in the macOS version. I've used previous CLion versions on macOS before for much larger projects and while there have been some performance ups & downs between CLion versions, it was never as bad as it is today.
One thing I have noticed while looking at the project structure, is that on macOS, under ‘External Libraries => Header search paths’, literally the *complete* macOS SDK is listed, even though my own code is not including any macOS framework directly (the only macOS specific things my project uses is MoltenVK and whatever clang pulls in for C++)
I have tried the CLion Nova EAP, and it does not have this problem, but it is not nearly solid enough for me to switch, it's missing a lot of stuff and generally runs verry buggy on macOS. So effectively using CLion for my macOS work is currently not really doable :-(
Please sign in to leave a comment.
Hello!
Sometimes such differences might be caused by differences in the implementation of standard functions/elements on Linux and macOS. I mean, going through some clang/libc++-specific template metaprogramming stuff might cause CLion to be slow, while on Linux they have another kind of template metaprogramming stuff there that doesn't trigger the issue. We have an issue about one of such cases - CPP-34600.
Feel free to provide examples to clion-support at jetbrains.com so that we can take a look at the particular issues you're facing.
Could you please specify what features you missed and what issues you faced?
Anna Falevskaya yes I can see how there will be differences between platforms, but this same project used to be fine with earlier CLion versions on macOS, so it's really a regression. And the difference really is so extreme (perfectly fine on Linux on low-spec hardware, vs some features completely unusable on macOS on high-end hardware) that it has to be a CLion problem and not just a platform difference.
> Could you please specify what features you missed and what issues you faced?
It's really so many it's not really helpful if I would list them here, death by a thousand cuts ;-). One particular thing I noted is that certain code formatting and inlay hints settings are not persisted correctly, and the inlay hints themselves seem buggy (sometimes they are shown while I have ‘only show when holding shift’ enabled, for example). But again, there's so many small things that don't seem as stable as the regular CLion version that I cannot really switch yet.
It's ok and expected though, because it's a preview version, so I'm not complaining, I will just try each update until it improves, and keep reporting IDE crashes every time I run into them (right now, I updated to the latest preview version and first thing it did was produce a crash popup, which was reported as a duplicate of DEXP-741589, for example)…
Please install CLion 2024.1 EAP and check if the issue still happens in it. If it does, please do the following:
Help | Collect Logs and Diagnostic Data;Hi Anna Falevskaya,
The problem is still happens in 2024.1 EAP.
I captured 2 CPU snapshots. One is for a ‘find related symbol’ operation to switch header/source in a relatively small project, this operation took ~30s on an M3 MacBook Pro. The other snapshot is a ‘rename symbol’ refactoring on a local symbol in a 200 line file of the same project. This operation took almost 3 minutes to complete. I will send these by e-mail.
-Wouter
Wouter, thank you for the provided snapshots! They show that the CPU is indeed consumed by code-resoling processes. We are going to address such problems by merging CLion Nova into CLion Classic when we fix the discovered bugs in CLion Nova and achieve decent product stability. Please follow updates in our blog - https://blog.jetbrains.com/clion/.
Regarding “this same project used to be fine with earlier CLion versions on macOS”: the difference might be caused by the new STL version on macOS.