1

Maybe, my question is stupid but I didn't find any answer and I really wonder to know it. When we have program with functions which are not called (they are for example only prepared for future implementation) I think that compiler read also these lines (minimally function declaration). It would be no problem but how about performance in bigger projects? Is there anything what we should avoid (for example some allocations / include files) which has bigger impact?

For example:

//never called/used
class abc{
...
}

//never called/used
float function_A(float x, int y){

...}

int main(){
...
}

This is just a short example but I think everyone know what I mean. Thank you very much!

astrak
  • 205
  • 1
  • 3
  • 9
  • 1
    Define "performance". – Quentin Sep 03 '14 at 07:55
  • 1
    This is called [dead code](http://en.wikipedia.org/wiki/Dead_code) and usually is considered bad practice. However, it is unavoidable in many cases (e.g. standard STL instantiation ...). If the compiler is optimizing well, it will remove dead code. – Basile Starynkevitch Sep 03 '14 at 07:58
  • For example application running time, memory usage, ... There are many points. I just wonder how it affects your application and if there are some problematic parts which are better to avoid. – astrak Sep 03 '14 at 07:59
  • 1
    Possible duplicate of [Do unused functions get optimized out?](https://stackoverflow.com/questions/6215782/do-unused-functions-get-optimized-out) – Donald Duck Jun 13 '18 at 02:00

4 Answers4

2

current implementations of compiler will not generate code for some kind of functions as you can read here. Non used code is typically not a performance hit especially if you declare and do not define the functions. Only functions with a lot of instructions can be a performance hit, but therefore I recommend you to read about instruction caching.

In bigger libraries you should care about include files. If you use and (more important) include them intelligently, you can gain performance at compile time. I.e use forward declarations in header files, and include headers in cpp files. Another thing is, if your split to a few header files, the compiler can skip whole .o files (which the compiler creates during compilation) at link time if they are not used. Hope this helped you a bit

Community
  • 1
  • 1
lifeOfPI
  • 318
  • 1
  • 8
  • Splitting the header files will have no impact on the object files. It's a pre-processing step on the source code. – darklon Sep 03 '14 at 08:08
  • as you stated it will not have impact on the object files, but on the behavior of the linker treating them – lifeOfPI Sep 03 '14 at 08:11
  • A type or function definition or forward declaration won't make it referenced function/class/whatever. So, it won't normally affect the linker. One exception would be if it actually declared an instance of a class, which is not something usually done in a header. Another exception I can think of is using something like #pragma comment(lib...), but that's compiler specific. – darklon Sep 03 '14 at 08:27
  • Thanks everyone for useful comments and links. I will have to read a bit more about that. – astrak Sep 03 '14 at 18:25
1

If you mean application performance, leaving in unused code will have no impact. The compiler does dead code elimination. But having to go through more code, the compiler will slow down slightly, so you will have to wait a bit longer for program compilation. Not including unused header files is a good idea, as one header file can pull in dozens or hundreds of others. (But precompiled headers can also help with that.)

darklon
  • 468
  • 3
  • 13
1

Instruction caching may still be an issue if unremoved dead code reduces locality of the program as a whole.

Imagine two functions A and B, where B is called from A repeatedly. If A and B fit into the same cache line, calling B from A is unlikely to produce a cache miss. But if a third function is placed in between the two functions by the linker so that A and B are not on the same cache line anymore, cache misses when calling B are becoming more likely, reducing overall execution speed.

While the effect may not be measurable very well and depend on a lot of other factors, reducing dead code is generally a good idea.

Florian Keßeler
  • 409
  • 3
  • 4
0

If the compiler can detect it as dead code, it will remove it completely and probably print a warning. If not, it will increases the object code size. With static linkage, linker will remove unused functions.

TNA
  • 2,595
  • 1
  • 14
  • 19