tags:

views:

224

answers:

8

Say you #include and never use anything from stdio.h. What are the overhead costs associated with this?

I noticed a lot of network code includes all networking related headers they can think of in case they end up using something from one of them, so I was wondering if this is some sort of ease of use vs efficiency trade off or if there is no loss of efficiency.

+10  A: 

Compile-time overhead, mostly, as the compiler has to include and parse that file.

Terry Mahaffey
Sometimes complicated includes make compile time severely bad.
sevity
@sevity - That's usually in C++, where includes can have lots of code and templates and hairy stuff. C includes can realistically only get so complex, and especially standard headers like `<stdio.h>` aren't going to be needlessly inefficient.
Chris Lutz
+2  A: 

Including files that are not needed will lead to slightly increased compilation times, but will have no effect on the generated code.

anon
+6  A: 

It should only impact compile speed only, not execution speed. As for the compile time overhead, for large projects it can be noticeable but the only way to know how it impacts your projects is to measure the compile times with and without the includes.

GregS
+4  A: 

There is no runtime efficiency loss. It's more of a maintenance issue as having superfluous includes makes it unclear as to what libraries you are actually using.

Whisty
+3  A: 

Precompiled headers in most popular compilers nowadays make the inclusion costs by #include pretty negligible. And at runtime nothing of that remains anyway since linkers are smart enough not to include things that aren't needed.

Joey
+2  A: 

Any overhead will primarily be at compile time rather than run-time.

The #include tells the compiler than it needs to include code from the referenced files. So it has to load the file when it comes across the reference. This will take a finite amount of time depending on where the file actually is and how large it is.

The only overhead at run-time would be if the compiler included code that wasn't referenced thus making the executable larger than it needed to be - which would potentially increase start-up times.

ChrisF
+3  A: 

Generally speaking, there is only compile time overhead not runtime overhead. The linker will only link against parts of the library that are really used by your program. Bad linkers will include the loading code for the referenced libraries even when they are not used at all, so you pay a little on startup time.

Johannes Rudolph
+1  A: 

It slows the compile down, of course. In the general case, It can also cause your your .exe to contain global variables or even functions that you never actually use.

For the standard C-runtime headers, I'm not aware of any significant runtime cost. For other headers you need to be careful. Some of the Windows headers declare hundreds of UUIDs that can end up bloating your exe.

The way you find out if this is costing you anything at runtime is to look at the .map file that the linker generates. Are there any variables or functions there that you didn't expect?

John Knoeller
I doubt any modern linker will include any global names that you never use.
Chris Lutz
@Chris - I wish this were true. But 'used' means something different to people than it does to linkers. linkers can't really tell the difference between that and 'referenced'. it's trivial for header files to have references that you don't really 'use'put `extern int _foobar;` in a header and see what happens.
John Knoeller