1

Which is more expensive in terms of processing costs

if ( x < 20 && z == "M") {
    // statements 3
}

if ( x >= 20 && w && x <= 65) {
    // statements 1
} 

if( x >= 20 && z == "F"){
    // statements 2
}

or this

if ( x < 20 ) {
    if( z == 'M') // statements 3;
} else
    if ( x <= 65 && w == true ) // statements 1;
    if ( z == 'F' ) // statements 2;
}
  • In the second block, you are avoiding the cost of evaluating x>=20. Not sure how much that saves in relation to the overall operations in the statements after the conditional checks. If one of these statements is y = sqrt(a) + sqrt(b) + sqrt(c);, you will probably not notice any significant savings. – R Sahu May 30 '14 at 4:02
  • 1
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat May 30 '14 at 7:41
  • I would probably favor second example... However, it should also depend on the domain... If 20 needs to be remplaced by 21, do you expect that all conditions should be affected or only one? If the rules are essentially independant, first example might be preferable. – Phil1970 Jun 17 '17 at 21:04
3

Profile them

....then you'll see which is most expensive.

In all seriousness, the answer you're looking for depended on many, many factors such as language (your example could be any if several languages), compiler, compiler settings, platform and runtime use.

If you only ever call this code a handful of times, the performance is irrelevant compared to the maintainability - go for easy-to-maintain version.

  • 1
    Unless this code is called thousands of times in an inner loop of a real-time shoot em up game, the performance is irrelevant. – user949300 Feb 11 '18 at 1:09
1

In terms of readability, you want to keep the conditions in if..else statements both mutually exclusive and collectively exhaustive. In other words, every test should match 1 and only 1 condition.

If you have unrelated conditions (say, "number of members" and "profitability"), you don’t want to taint them by &&ing them together. So in most cases, it is better to have nested if..else blocks.

if (members <= 100) {

  if (nonProfit) {
    // ...
  } else if (notForProfit) {
    // ...
  } else {
    // ...
  }

} else if (100 < members && members <= 1000) {

  if (profitable) {
    // ...
  } else {
    // ...
  }

} else {

  // ...

}

With more rigid conditional structures though (e.g., repeating if..else blocks), you are probably better off using object lookups. Not only are object lookups faster, but they are much more readable and easier to understand in my opinion. They are less flexible than if..else, which can be either advantageous or disadvantageous based on your requirements.

1

What you are doing is called "micro-optimisation" but would better be called "nano-optimisation". It's absolutely not worth even attempting. If you want to make code faster, that's a problem that needs to be attacked at a much, much higher level.

At that level, make your code as readable as possible. Make it as maintainable as possible. Anything to reduce the time to produce correctly working code. Now you can use the time saved to do some real optimisations (if that's of importance to the users; most likely they will be happier with having more features). And having readable and maintainable code makes it easier or even possible to do real optimisations that save measurable time.

And let's just say that your two versions of the code are not equivalent. One, the are not equivalent because you made some mistakes. That's one problem with that kind of optimisation; if you are not focussed enough to avoid stupid mistakes, then attempts of optimisation lead to failure. And the other problem is that "statements 3" might change the value of x, in which case there's a huge difference between both codes.

0

Assuming you are doing this in C or C++, and assuming a production-quality compiler:

If x was declared "volatile", the first will be slightly more expensive, and the second may yield incorrect results.

If x was not declared "volatile", and optimization is on, they should yield identical code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.