23

I want to reduce compile time of a large C++ project. I tried to use precompiled headers, interface and etc. But before I move on, I want to know whether any tool which helps detect why compile time is so long. Somebody suggests pc-lint and I will give a shot. How should I detect unnecessary #include files in a large C++ project? But if there are other tools which analysis compile time and talk about any hints to increase compile speed, let me know. Thanks in advance.

Environment : Microsoft Visual Studio C++ 2008 or 2010.

Community
  • 1
  • 1
P-P
  • 1,670
  • 5
  • 18
  • 35
  • 1
    Not directly an answer, but you did turn parallel build on? – dbrank0 May 14 '12 at 05:22
  • General comment is don't include headers you don't need. The worst thing for build time is a header file called includes.hpp that includes all the possible header files you need. I've seen that bloat re-compile time. – David Mokon Bond May 14 '12 at 05:27
  • 6
    How about a hardware upgrade? – Jesse Good May 14 '12 at 05:27
  • Make sure you have a proper build system which only rebuilds those files that have changed. Then you can use things like PIMPL to minimize the amount of coupling and compilation dependencies. – Kerrek SB May 14 '12 at 05:33
  • @David: I'm doing that all the time ... each header equipped with a '#ifndef foo \n #define foo ... #endif' of course. Should I not? – steffen May 14 '12 at 05:45
  • @steffen So I could be wrong on this so I would be happy to be proven wrong my understanding is lets say I have a file obj.c which include inc.h which includes h1.h and h2.h. If I change something in h2.h and I only need h1.h in obj.c that means obj.c still needs to be rebuilt since the timestamp on h2.h has been touched and inc.h has a dep on h2.h and obj.c has a dep on inc.h... Than again I could be wrong... But from my experience I changed a project from this method and compile time speed up a TON... – David Mokon Bond May 14 '12 at 05:49
  • @steffen: we are not talking about guarding your headers (which is mandatory), we are talking about avoiding the `#include` directive as much as possible in headers, because it creates dependencies and rebuild-from-hell. – Matthieu M. May 14 '12 at 06:48
  • Ask does the program need to be this complex? Every time I speed up a build, someone just increases the complexity of the program until it takes exactly the same time as it did before. – ctrl-alt-delor May 14 '12 at 11:40
  • @steffen Just use `#pragma once`. The compilers understand it well. – Alexander Shishenko Aug 27 '16 at 23:52

4 Answers4

5

one approach i like is to review the preprocessor output of a few of your sources -- just read some of it from the compiler's perspective rather than the somewhat abstracted representation that is #inclusion. chances are you will find some large chunks of includes/libraries you don't need and weren't necessarily aware of the existence (or need) of the dependency/include. from there, decide which dependencies can be removed. even if your dependencies were all correct, large outputs can also suggest how you might approach dividing larger modules into smaller pieces.

justin
  • 104,054
  • 14
  • 179
  • 226
4

C++ not being modular (yet), compilation bottlenecks are often due to include issues; that is using including too many files when they are not needed. It is also possible that those includes are needed at the moment, but could become superfluous with some simple reengineering.

  • to detect superfluous includes, you can check include-what-you-use, the only issue you'll have is that it works on top of Clang, so you'll need some setup there.
  • otherwise, you need to review your code, and specifically the headers.

Since the tool is self-sufficient and documented, let me expand a bit on the review process.

  1. Any header that has more than a couple #include is highly suspicious.
  2. On the contrary, if you have a source file chock-full of various types and functions and it only has a couple includes, it probably means that one of the headers brings too much.

If you have trouble knowing what is required, what is not, and how to remove superfluous headers, I recommend a reading of Pimpls - Beauty Marks You Can Depend On; if you do not know what a Pimpl is, read Compilation Firewalls. I would advise cautiousness though, Pimpl has a runtime and maintenance cost, so only use it when it really is necessary. Personally I would absolutely recommend it in the public headers of a library you deliver to 3rd party (ABI compatibility), and otherwise try to avoid it.

If manual inspection is not your forte, you can generate the preprocessor output for each header (do not worry about source files too much), and check the bigger outputs.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
3

I am not aware of any tool for betterment of the compile time, but few manual remedies, I can suggest (consider this as comment):

  1. Have #include guards with every header file, so that multiple inclusions won't make any issues
  2. Reduce member function body, inline function body putting directly into the header files; just have their declarations
  3. Check if there are no unnecessary template function and classes; remember that tempaltes become inline by default. Too much of templates/metaprogramming cause huge compilation time.
  4. If number of #defines are unnecessarily high then they would increase preprocessing stage, which ultimately increases the compilation time
iammilind
  • 68,093
  • 33
  • 169
  • 336
2

You could look into unity builds.
Basically it's including all .cpp files into one .cpp file and only compiling that one file. I've tested it on a big project and it was really effective.
It works because of it uses much less I/O when it includes all your headers/cpp's once and not for every cpp.

Now we don't use unity builds anymore because we all got a SSD hardware upgrade, and they are just awesome.

Here's a related SO question about Unity builds: #include all .cpp files into a single compilation unit?

Community
  • 1
  • 1
Stormenet
  • 25,926
  • 9
  • 53
  • 65
  • +1 - very interesting comment on Unity Builds - I will have to try that the next time I touch a low-level header. As for SSDs, I'm late to the game: just added it to a laptop after a HDD crash - the speed increase suggested that I should change the compile box to SSD. After your comment, I will definitely make the change, once capacity is a bit higher/price a bit cheaper. – kfmfe04 Dec 22 '12 at 20:26