c++ - Code execution slowing due to header include

We have a very large program here which mixes C++ and FORTRAN (sorry). One of my check-ins has resulted in a dramatic slowdown of the complete application (i.e. by a factor of two or more) - even in areas of the code which are not affected by my changes.

The facts:

1. Almost every module has slowed by a similar amount - even ones which use none of my code.




2. The executable is about 6% bigger.




3. The metadata has not been changed between check-ins.




4. The IDE/compiler is VS2010 in Release mode.




5. Some .lib files have doubled or tripled in size.

I looked at one of the .lib files which has tripled in size, and there are only two changes:

a) I have included a large-ish header file which in turn includes many others - some of which contain moderately complicated inline code. The 'Additional Include Directories' has gone from none-or-one to about 7, as each header file #includes one or more others.

b) I have called 4 functions from out of this header file, but these are not called during the run that has slowed down (i.e. their execution cannot be slowing the code down, but their inclusion might conceivably be).

In spite of searching the forums as to whether including header files slows down execution (as opposed to compilation), I can't find a single relevant article. My questions are:

? Does the #inclusion of any form of header (declaration or inline) slow down the code execution?

? Is there are qualitative or quantitative difference in the inclusion of inline code w.r.t. execution speed (I know that 'inline' is only advice to the compiler)?

? What are the correlations between .lib size, .exe size and execution speed (I'm expecting lots of different and contradictory correlations here)?

? Will refactoring some of the header files such that they don't need to include others (by putting these includes into a .cpp file, and thus reducing my 'Additional Include Directories') improve my situation, do you think?

I guess the last question is the meat of the issue, as it will take a lot of effort...

Answer

Does the #inclusion of any form of header (declaration or inline) slow down the code execution?

Adding unused declarations nor adding unused inline definitions does not slow down execution. I can however imagine several things that can slow down execution:

• Some #define that prevents optimized inline or macro variants of commonly used functions to be provided by another header further down the line.


• Overload for some operation that is commonly used, possibly from within standard library, that is less efficient than the default.

Is there are qualitative or quantitative difference in the inclusion of inline code w.r.t. execution speed (I know that 'inline' is only advice to the compiler)?

Well, if the code is not available, it can't be inlined. If it is, that it can. Usually the compiler can estimate how much inlining will save and not inline if it won't help, but occasionally it can guess wrong. In such case the result will be wildly different from the usual case where it slightly helps.

What are the correlations between .lib size, .exe size and execution speed (I'm expecting lots of different and contradictory correlations here)?

Completely different case by case. Inlining inflates the code size, but can save a lot of work on each call site. But larger code takes up more cache, which slows it down.

Will refactoring some of the header files such that they don't need to include others (by putting these includes into a .cpp file, and thus reducing my 'Additional Include Directories') improve my situation, do you think?

It may or may not. Depends on the actual cause.

I propose you should really try to find the cause. It is almost certainly caused by some particular bit of code, not the amount of code included. So go back to revision before the change and add the included bit by bit. First include the innermost headers alone and than add the headers that use them and so on, one by one. When you get to the particular header that makes things worse, try commenting out bits of it until you narrow it down to particular declaration or few of them.

Also take out just some function where you observe the performance degradation. Than if you narrow it down and still don't see what could be wrong, you'll have something on that others can reproduce the issue, so you can use it as new question.