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; } 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.
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.
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.
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.
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 isy = sqrt(a) + sqrt(b) + sqrt(c);, you will probably not notice any significant savings.