1

I have written a program in C that has several different versions of a certain function. I select which one to use based on hardware considerations and change the single call I make to this function before compiling. I usually go to the trouble of commenting out the unused functions as well. But I'm wondering what effect leaving them uncommented would have.

It seems to me that if they are never called they won't have any effect on execution time at all. But they will increase the size of the executable. Since the executable size is small anyway, that doesn't bother me. The only thing that matters is execution time, and that is critical. So it seems that commenting out the unused functions isn't worth the trouble. Am I right?

Improve this question
5
  • 4
    You can use #if 0 ... #endif instead. For that matter, if you use a series of #ifdefs, you can define a symbol on the compiler's command line to control which function is compiled (which may or may not be a good thing). Commented Feb 26, 2014 at 0:21
  • 1
    If there was an execution-time inefficiency with having unused functions in your code, I'd imagine that the #includes would cause a much bigger problem than a few extra user functions. Commented Feb 26, 2014 at 0:22
  • Since you haven't posted any code, any comments or answers are just opinions. If you want to know the effect of changes on runtime performance the only definitive way is to do some testing. I'd have thought that getting your build system to include only the version of the function you want based on some compile-time flag would be a more reliable way of managing the codebase than manually commenting code. Commented Feb 26, 2014 at 0:23
  • @MikeW: is that really true? I agree that the only definitive way would be to test it, but once you found that it does effect the performance, wouldn't that be the case in general and scalable, so-to-speak, based on the machines "power". IOW, if it matters on one machine, wouldn't it matter on all machines? (All things equal of course; i.e., compiler settings, etc.) Commented Feb 26, 2014 at 0:42
  • I wouldn't call myself a beginner, but I'm not an expert either. I don't really know what my options are to prevent the code from being compiled. I looked into using some kind of macro wrapper, but I think that only works if you have multiple source code files with headers. Which is why this situation might be different from just including a library. From my research it sounded like my best option was the comment method. As far as posting my code, I agree with Bobby, this was actually meant as a more general question about technique, not only for this but for future projects. Commented Feb 26, 2014 at 1:40

3 Answers 3

Reset to default
6

If you compile with optimizations and (MSVC) Link Time Optimizations or (GCC/Clang) -flto, unused functions will generally be removed, which makes it a moot point.

Otherwise, unused functions will tend to have very little impact on runtime performance, potentially even zero. They will increase executable size and so increase loading times.

Where they can have any non-zero bearing on performance is in causing otherwise compact code to become spread out across memory. If a significant portion of your codebase is unused/unreachable code, this might become noticeable.

Instead of "commenting out" routines, use compiler directives:

#define WINDOWS_x86 0 #define WINDOWS_x64 1 #define WINDOWS_ARM 2 #define LINUX_x86 3 #define LINUX_x64 4 #define LINUX_ARM ... #if defined(WINDOWS_x86) || defined(WINDOWS_x64) void doAThing() { ULONG x = 0; ... } #elif defined(WINDOWS_ARM) void doAThing() { MessageBoxA("You too cheap to buy real computer. I no calculate for joo"); } #elif defined(LINUX_x86) ... #endif
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

I should have mentioned that I use Visual Studio. But there must be an equivalent setting there. I think compiler directives might be the best solution though.
MSVC = Visual Studio. Select the "Release" build from the build drop down (it defaults to Debug), go to Properties for the solution. Enable "Whole Program Optimization" under "Configuration Properties" >> "General", Under C/C++ >> Optimization, Set optimization to "Full Optimization" and enable "Enable intrinsic functions", "Omit Frame Pointers" and "Whole Program Optimization" - you may need to experiment with "Favor Size or Speed". Under C/C++ Code Generation look at turning off C++ Exceptions unless you're using them, "Bufer Security Check" to No and "Enable Enhanced Instruction Set".
Lastly, under "Linker" >> "Optimization" enable Link Time Code Generation.
I have done some experimenting and I can't seem to find much difference, no matter what I do. Leaving in the dead code, commenting it out, declaring it as static, using compiler directives, setting optimization settings... in each case the resulting executable is exactly the same size. Maybe VS is pretty good at removing this stuff. I think the commenting method is for debugging and the compiler directive method is for code that is meant to remain in the final version, for whatever reason, but not used. Another reason not to use the comment method is VS nukes all your indents as soon as it can
1

Code size matters for execution speed.
You can get the compiler to simply omit the code as dead code though:
If the function is only called from within its own compilation unit, adding the static qualifier to the function declaration lets the compiler know it won't be called from outside of the compilation unit. If the compiler can then see it's not called from within either, it can throw away the code (and may put out a warning like "unused function").
If you have some sort of link-time optimization, it may be able to do the same for code in separate compilation units, but that's a bit more expensive, compilation-time wise.

Improve this answer

1 Comment

I like this idea because it seems to involve the least amount of work. I wonder if there is a way to tell if the compiler is actually including the dead code or not? I guess I could try compiling with and without commenting the unused functions and compare the resulting executable sizes.
1

OK, here is some real-life testing on my computer:

Test1.cpp:

int foo() { int x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; x = x % x; } int bar(void) { return 0; } int main() { bar(); return 0; }

Test2.cpp:

int bar(void) { return 0; } int main() { bar(); return 0; }

Tested for 10,000 times (CPU cycles measured):

Test1.cpp 6.044 s Executable size: 7,355 bytes Test2.cpp 6.036 s 7,331 bytes

All in all, it seems like a small performance boost can be achieved, but my results I would chalk up to negligible inefficiencies. Keep in mind, though, that this is without any of the built in libraries. I can guarantee that they will be more code heavy than 50 modulus operations.

Part 2:

Test3.cpp:

#include <stdio.h> #include <stdlib.h> int bar(void) { return 0; } int main() { bar(); return 0; }

Test4.cpp:

int bar(void) { return 0; } int main() { bar(); return 0; }

Results

Test3.cpp: 5.960 s Executable size: 7331 bytes Test4.cpp: 6.176 s, 5.964 s, 6.116 s Executable size: 7331 bytes

It seems like the compiler does a pretty good job of dealing with these things. After including some larger libraries, it seems like they are removed from the file.

Improve this answer

2 Comments

It will also depend on your compiler and settings, as I am pretty sure that they are capable of detecting unused code and throwing it away.
Agreed. But for the purpose of learning, I'm not using any of those to demonstrate the effect.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.