c ++尝试通过替换测试来优化代码

Question

I am looking at code that someone else wrote, and it has a lot of debug sections, of type

if(0) { code }

or if(1) { code }

or if(false) { code }

There is even

#if(0)
#endif

(which did not turn gray though - I thought that it should)

I was wondering, if I replace these with some #if 0 (or #ifdef _DEBUG ), is it possible to optimize the code ? - or - it will not make any difference ?

I think that it may help, since I have seen code that is within these sections being grayed out - and I thought that this code is removed from the Release executable... Therefore making it faster. Is that true ?

The code that I am thinking of is inside functions that could be called lots of times...

Edit: The code I am referring to is being run millions of times. I am aware that the contents of the if(0) will be ignored...

I am also aware of the benefit of being able to easily debug an issue, by switching a test from 0 to 1...

My question was, the fact that I am adding millions of millions of times the test if(0) does not add overhead... I am trying to figure out what are all the things that could make this code take fewer hours.

Answer 1

If expressions placed inside those IFs are constant and determinable at the time of compilation , then you may be almost sure that the compiler has already removed them off the code for you.

Of course, if you compile in Debug-Mode, and/or if you have optimization-level set to zero, then the compiler may skip that and leave those tests - but with plain zero/one/true/false values it is highly unlikely.

For a compile-time constant branches, you may be sure that the compiler removed the dead ones.

It is able to remove even complex-looking cases like:

const int x = 5;

if( 3 * x * x < 10 ) // ~ 75 < 10
{
    doBlah(); // skipped
}

However, without that 'const' marker at X, the expression's value may be not determinable at the compile time, and it may 'leak' into the actual final product.

Also, the value of expression in following code is not necesarily compile-time constant:

const int x = aFunction();

if( 3 * x * x < 10 ) // ~ 75 < 10
{
    doBlah(); // skipped
}

X is a constant, but it is initialized with value from a function. X will most probably be not determinable at the time of compilation. In runtime the function could return any value*) so the compiler must assume that X is unknown.

Therefore, if you have possibility, then use preprocessor. In trivial cases that won't do much, because the compiler already knew that. But cases are not always trivial, and you will notice the change vrey often. When optimizer fails to deduce the values, it leaves the code, even if it is dead. Preprocessor on the other hand is guaranteed to remove disabled sections, before they get compiled and optimized. Also, using preprocessor to do that at least will speed up the compilation: the compiler/optimizer will not have to traceconstants/calculate/checkbranches etc.

*) it is possible to write a method/function which return value will actually be determinable at the compilation and optimization phases: if the function is simple and if it gets inlined, its result value might be optimized out along with some branches.. But even if you can somewhat rely on removing the if-0 clauses, you cannot rely on the inlining as much..

Answer 2

If you have code inside an if (0) block, the code generated by the compiler will be the same as if that block wasn't there on any reasonable compiler. The code will still be checked for compile-time errors. (Assuming you don't have any jump labels inside it or something weird like that.)

If you have code inside an if (1) block, the code generated by the compiler will be the same as if the code was just inside braces. It's a common way to give a block of code its own scope so that local variables are destructed where desired.

If you ifdef out code, then the compiler ignores it completely. The code can be completely nonsense, contain syntax errors, or whatever and the compiler will not care.

Answer 3

Typically, #if 0 is used to remove code whilst still keeping it around - for example to easily compare to options, I sometimes do:

#if 1
   some sort of code 
#else
   some other code
#endif

That way, I can quickly switch between the two alternatives.

In this case, the preprocessor will just leave one of the two options in the code.

The constructs of if(0) or if(1) is similar - the compiler will pretty much remove the if, and in the case of 0 also remove the rest of the if-statement.

I think it's rather sloppy to leave this sort of stuff in "completed" code, but it's very useful for debugging/development.

Say for example you are trying a new method for doing something that is much faster:

if (1) 
{
   fast_function();
}
else
{
    slower_function();
}

Now, in one of your testcases, the result shows an error. So you want to quickly go back to slower_funcion and see if the result is the same or not. If it's the same, then you have to look at what else has changed since it last passed. If it's OK with slower_function, you go back and look at why fast_function() is not working as it should in this case.

Answer 4

It's true (depending on your build settings and preprocessor).

Putting debug code in #ifdef _DEBUG (or similar) is a standard way to keep these completely out of your release builds. Usually the debug build #define s it, and the release build does not.

Usually, though, a compiler should also remove code such as if (0) , if given the proper optimization flags, but this puts extra work on the compiler, and on the programmer (now you have to go change them all!). I'd definitely leave this to the preprocessor.

Answer 5

You're correct. If you compile with #define DEBUG 0 then you will be actually removing all the #if DEBUG blocks at compile time. Hence, there will be lot less code, and it will run faster.

Just make sure you release your code after making #define DEBUG 0 at release time.

A good optimizing compiler(GCC, MSVC) will remove if(0) and if(1) from code completely... the translation to machine code will NOT test for these conditions...