2

What is the easiest way to know whether a certain chunk of code will be optimized in a certain way, in Visual Studio?

For example, the line marked below is very likely to be optimized out.

int main(){
    int a=3; //####
    std::cout<<"1234"<<std::endl;
}

This can be checked moderately easily by setting a break-point, it will be grey-out.

What if the code is more complex?

Below are just examples.
It would be ideal if I can know it without compiling.

Example 1

int f1(){
    return 3;
}
int main(){
    int a=f1(); //#### likely to be in-line ?
    std::cout<<a<<std::endl;
}

How can I be sure about that f() will be in-line?

Example 2

void f2(bool a){
    if(a) std::cout<<"T"<<std::endl;
    else std::cout<<"F"<<std::endl;
}
int main(){
    f2(true);
    f2(false);   
}

How can I know whether f2() will be optimized by split into 2 functions like this:- 

void f2_true(){         std::cout<<"T"<<std::endl;    }
void f2_false(){        std::cout<<"F"<<std::endl;    }
int main(){
    f2_true();
    f2_false();
}
Cœur
  • 37,241
  • 25
  • 195
  • 267
javaLover
  • 6,347
  • 2
  • 22
  • 67
  • 5
    Could you just look at the assembly, like [this](http://stackoverflow.com/questions/1020498/how-to-view-the-assembly-behind-the-code-using-visual-c)? – TartanLlama Aug 09 '16 at 09:42
  • Great, that is a kind of answer I am looking for. Thank! – javaLover Aug 09 '16 at 09:43
  • 4
    _"What is the easiest way to know whether a certain chunk of code will be optimized in a certain way, in Visual Studio?"_ The easiest way is _not_ to! – Lightness Races in Orbit Aug 09 '16 at 09:43
  • 2
    But yeah, as @LightnessRacesinOrbit notes, you shouldn't really care about whether or not some code is optimised in a certain way. Write your code, profile it, if some parts run slower than you would like, optimise them. – TartanLlama Aug 09 '16 at 09:45
  • 2
    Finding out how some random part of your code gets optimized is most likely not useful anyways. Humans are quite bad at predicting performance. – Baum mit Augen Aug 09 '16 at 09:47
  • Agree... I just think ... if I know the result, I might be able to optimize it *a little* more efficiently. – javaLover Aug 09 '16 at 09:48
  • 2
    @javaLover The most (and probably only) efficient way of optimizing is finding out what parts are too slow by measuring and then making them faster. Optimizing based on guessing (the performance of the generated assembly for example) may a) make your code slower because humans are bad at guessing and b) make your code harder to read / more complicated / more buggy than the most straight forward way of doing it. Thus, it usually is a major waste of time. Look up "premature optimization". – Baum mit Augen Aug 09 '16 at 09:54
  • Thank for detailed-and-high-quality explanation. I have learned some knowledge from you, and I am strongly discouraged now. However, in some rare cases, I just want it (e.g. example 2). – javaLover Aug 09 '16 at 10:02
  • @BaummitAugen: There are exceptions. For time-critical code such as machine vision libraries, predicting optimization is a must. –  Jul 30 '17 at 10:43

1 Answers1

3

As mentioned multiple times in the comments, predicting the optimization is not useful. However, you can let your compiler give you some information of what optimizations he actually did. For example you can use the options /Qvec-report:2 with the warnings at least at level 4 (/W4) to get information about the vectorization of code. The Microsoft webpage has detailed information on how to interpret the output of this option. I found this option very useful to achieve parallelization of critical code fragments, which resulted in performance gains of up to a factor of 4.

I suppose there are other flags to let the compiler be verbose about other optimizations.

Paul R.
  • 678
  • 5
  • 19