Overhead in unused code

Question

I am wondering what the overhead is of having unused functions in your code.

Say for example you have some debug logging, and you then give most of your objects a ToString() function that is being used in the debug logs.

In a release build that debug logging is not being used. Is it then worth it removing the source code of those ToString() functions? (e.g. via Macro?)

Or do they just make the executable marginally larger and otherwise don't impact performance? e.g. no speed impact? Or does the compiler or linker possibly even remove the functions if they are not used? If the compiler or linker don't remove the code, what if the ToString() functions were defined inline? Presumably it would try to inline the code, and since the function is never called, it would disappear?

I imagine every function needs to be retained in a static lib, but once compiled to an executable, surely a lot of stuff just gets ignored by the linker?

On another note that is roughly similar, if the compiler chooses not to inline an inline function, so that the inline function is defined as function in several compilation units, will the linker chuck away the superfluous definitions and only link one of them at the end?

Thanks

Answer 1

It depends on the compiler and, I guess, optimization level.

G++ and MSVC++ remove unused inline functions but keep unused non-inline functions. For instance, you use only a small fraction of the STL in a normal program. All unused functions get removed, because they're defined as inline.

GCC on the other hand keeps all functions, even unused inline ones.

Answer to your other question: if a function is somehow defined in multiple compilation units, the linker will frown and refuse to link, unless if it is defined as inline.

Answer 2

1. Regarding Compilers and Linkers

It really depends how you create your executable.

Typically executables are stripped of anything that is not used. Therefore if you link statically (and with the right optimization options) the functions will get removed.

However if you link dynamically, they'll be there, because as far as the library is concerned, they are exported and therefore used.

As for the multiple definitions, it depends if the symbol is weak. If it's weak, the linker picks one of the definitions, otherwise it chokes on it.

Finally, they probably only represent a marginal part of your program.

2. How to solve the issue ?

It's a hard problem, you can always use the preprocessor to remove some stuff, but code that is littered with preprocessor directives is really annoying to read.

Personally, I would not bother... especially because I log in Release too (how else tracking down production issues ?).

A solution could be to define the offending functions in a separate file and not link them in Release. Note: I do not think it works for virtual functions, since they are at least used in the vtable