Best practices for CMake files for use in CLion


The time it takes to complete a reload CMake files seems to continuously going up. There's the time it takes to actually run CMake, but that is a small part of the total time it takes since CLion also spends a lot of time on indices.

This time seems to be steadily increasing for my project. The index building used to take about 30 seconds (version before 2016.1), then during 2016.1 EAP it crept up to 85 seconds, and now with a recent EAP I think it is starting to go above 100 seconds.

I noticed that I could significantly reduce the reload time by mark all my gtest applications as excluded (over 50 gtest projects). This drops the reload cmake file time for my entire application to about 15 seconds. That is however not ideal since my gtest applications then are ignored. This in turn leads to a 200+ contexts and I'm suspecting that each context comes at a price. There are four contexts per binary, right?

Reloading the cmake files taking a long time wouldn't be a big deal except for the fact that I need to reload the cmake file every time I add a cpp-file. Waiting that long every time you add a class is a problem.

I wouldn't be surprised if we are doing something in the cmake files which is sending CLion for a goose chase for no good reason. Are there best practices for how to construct a CLion friendly CMake environment? Things to avoid? Ways to optimize?

For instance, we have something called CoreLibs. This is a set of libraries that are commonly used. We tend to include them in each gtest app, however, even if they are used often, for each individual app we are probably using less than half of those libraries. I'd be willing to go through and optimize our build environment so that each test app only has the libraries it needs and nothing else. Problem is, that would take days and I don't know if it'll have any effect at all.

From a feature point of view I'd love it if the re-loading the cmake files could be made faster (and note, the running of cmake itself is only about 5 seconds). I'm not sure how you could improve things, but I understand that you are creating four contexts per application by default. I tend to change from debug to release or vice versa far less often than I add classes so that might be a possible avenue. I'd much rather have changing from release to debug take a really long time than to add a class.

Comment actions Permalink

Hi Olof.

Thanks a lot for the detailed case! We are sincerely sorry for the inconvenience due to performance issues. We have a related feature request in the tracker already: Please add your comments there and try using a workaround (set CMAKE_CONFIGURATION_TYPES variable: Also we would be grateful if you could capture a CPU snapshot and send it to clion-support at It would help us to understand if there is something that we could improve in performance besides that issue for your case.

Comment actions Permalink


I have it do Debug only and that cut the building of indexes down to 27 seconds. 


I think most people typically would want to have at most Release and Debug and not the other two defaults. That would make CLion twice as fast for adding files so you might want to put that front and center so people know that is an option. Maybe have a little performance tweaking document for users, or maybe when creating a new project ask the users which targets they want. Or maybe even that the CMakeLists.txt file that you create could have it set to be Debug and Release only as the default.


Please sign in to leave a comment.