14

How do I find which parts of code are taking a long time to compile?

I am already using precompiled headers for all of my headers, and they definitely improve the compilation speed. Nevertheless, whenever I make a change to my C++ source file, compiling it takes a long time (this is CPU/memory-bound, not I/O-bound -- it's all cached). Furthermore, this is not related to the linking portion, just the compilation portion.

I've tried turning on /showIncludes, but of course, since I'm using precompiled headers, nothing is getting included after stdafx.h. So I know it's only the source code that takes a while to compile, but I don't know what part of it.

I've also tried doing a minimal build, but it doesn't help. Neither does /MP, because it's a single source file anyway.

I could try dissecting the source code and figuring out which part is a bottleneck by adding/removing it, but that's a pain and doesn't scale. Furthermore, it's hard to remove something and still let the code compile -- error messages, if any, come back almost immediately.

Is there a better way to figure out what's slowing down the compilation?

Or, if there isn't a way: are there any language constructs (e.g. templates?) that take a lot longer to compile?

What I have in my C++ source code:

  • Three (relatively large) ATL dialog classes (including the definitions/logic).

    They could very well be the cause, but they are the core part of the program anyway, so obviously they need to be recompiled whenever I change them.

  • Random one-line (or similarly small) utility functions, e.g. a byte-array-to-hex converter

  • References to (inline) classes found inside my header files. (One of the header files is gigantic, but it uses templates only minimally, and of course it's precompiled. The other one is the TR1 regex -- it's huge, but it's barely used.)

Note:

I'm looking for techniques that I can apply more generally in figuring out the cause of these issues, not specific recommendations for my very particular situation. Hopefully that would be more useful to other people as well.

Community
  • 1
  • 1
user541686
  • 205,094
  • 128
  • 528
  • 886
  • "but of course, since I'm using precompiled headers, nothing is getting included after stdafx.h." Just because you use precompiled headers doesn't mean that you stick _everything_ in the PCH. You put the commonly used stuff there, as well as the stuff that takes a long time to compile. – Nicol Bolas Nov 12 '11 at 19:42
  • Can the code be refactored to be split in to multiple source files? – Scott Chamberlain Nov 12 '11 at 19:42
  • What's the speed on individual CPP files? Are certain ones taking longer? – Pubby Nov 12 '11 at 19:42
  • @NicolBolas: Yes, that's exactly what I'm doing. There's nothing left... – user541686 Nov 12 '11 at 19:43
  • @ScottChamberlain: I *guess*, although that's more of an alternative rather than a diagnosis technique. – user541686 Nov 12 '11 at 19:44
  • @Pubby: I haven't tried testing it extensively, but some of my projects *do* appear to take longer than others. It would take me a while to figure out why, though, since I'd just have to dissect all the source files, which doesn't really scale well... (Each project only has 1 or 2 C++ files, since the "project" is pretty small. So it's hard to compare in the same project.) – user541686 Nov 12 '11 at 19:45
  • Any chance that you can post your code? – Pubby Nov 12 '11 at 20:01
  • @Pubby: lol, not really. But I can post descriptions of what I have in it; will do in a few minutes. – user541686 Nov 12 '11 at 20:09
  • 2
    @sehe: I've never seen that on VS2008. You can't include files (or do anything) _before_ the PCH, but you can generally include whatever you want afterwards. I do this all the time, where I PCH a bunch of library headers (Boost) in a project, but the headers defined _within_ that project aren't in the PCH. It works fine for me. – Nicol Bolas Nov 12 '11 at 20:26
  • @NicolBolas: my mistake, I had it in reverse. I get annoyed with stdafx, which is why I normally disable it. I like to prevent copmilation alltogether by minimizing dependencies and having good build rules. PCH has its merits, but the way VS 'enforces' it is not a big help in my experience – sehe Nov 12 '11 at 20:35
  • In my experience, C++ projects usually take too long to compile because the project is split up into multiple *translation units* which are all pulling in redundant header files. Google *C++ translation unit*. – James Brock Nov 12 '11 at 21:41
  • @JamesBrock: I only have 1-2 C++ source files per project, so that shouldn't be the issue. – user541686 Nov 12 '11 at 21:43

2 Answers2

4

Two general ways to improve the compilation time :

  • instead of including headers in headers, use forward declare (include headers only in the source files)
  • minimize templated code (if you can avoid using templates)

Only these two rules will greatly improve your build time.

You can find more tricks in "Large-Scale C++ Software Design" by Lakos.

For visual studio (I am not sure if it is too old), take a look into this : How should I detect unnecessary #include files in a large C++ project?

Community
  • 1
  • 1
BЈовић
  • 62,405
  • 41
  • 173
  • 273
1

Template code generally takes longer to compile.

You could investigate using "compiler firewalls", which reduce the frequency of a .cpp file having to build (they can reduce time to read included files as well because of the forward declarations).

You can also shift time spent doing code generation from the compiler to the linker by using Link-Time Code Generation and/or Whole Program Optimization, though generally you lose time in the long run.

Michael Price
  • 8,088
  • 1
  • 17
  • 24