skipping "else" statement is faster?

hello
take these two function examples which should do the same thing:

Code:

---

// standard way
bool function () {
        if (a == 0) {
                return false;
        }
        else if (a > 0){
                return max (a);
        }
        else {
                return min (a);
        }
}

// non-standard way
bool function () {
        if (a == 0) {
                return false;
        }
        if (a > 0) {
                return max (a);
        }
        return min (a);
}

---

It's obvious that the first way is easier to read and way better to do things
I am wondering if the second way would be faster once compiled, or not.

That would depend on your compiler, and what options you have set for it.

I can't agree that the first way is "way better", at all. The second way seems very "clean" and perfectly straightforward.

Unless you're compiler is smart, I'd bet on the second way being faster - but what are you really talking about for a difference here? I LIKE nit-picking, but here we're approaching something probably in the thousands of a second, or less?

My enthusiasm wanes at that point.

A smart compiler should be able to optimize either function to the same assembly code I believe.

Quote:

---

Originally Posted by adak

but what are you really talking about for a difference here?
I LIKE nit-picking, but here we're approaching something probably in the thousands of a second, or less?

---

It's probably much less than a thousand of second, but if I'd had to call that function 324,153,423,484 times, that wuold make some difference.
By the way, it's more funny if I always search for the better way to do something

Aye, on gcc-4.1.2, they both create the same assembly code, I'd assume most other modern compilers would do the same.

Quote:

---

Originally Posted by MacGyver

A smart compiler should be able to optimize either function to the same assembly code I believe.

---

Is the gnu compiler (gcc - g++) supposed to be "smart"?

edit: oops I posted this before reading the post above ^^
Thanks all, my question is answered

On a side note, some coding standards, such as that of Mozilla, require you to omit redundant elses, i.e. to go for option #2 in this scenario. I'm not sure about the exact reasoning behind that.

As others have said, most modern quality compilers will do the same thing, regardless of how the function is coded. The choices are stylistic, not functional.

Those who dislike multiple returns from functions would probably do this;

Code:

---

bool function ()
{
        bool retval = false;
        if (a > 0)
            retval = max(a);
        else if (a < 0)
            retval = min(a);
        return retval;
}

---

Again, any reasonably modern/quality compiler will probably do the same with this as with other examples above.

The reason for omitting redundant elses in code is related to proveability and elimination of dead code: it is more difficult to formally prove if a redundant else clause is or is not entered.

Quote:

---

Originally Posted by carlorfeo

hello
take these two function examples which should do the same thing:

Code:

---

// standard way
bool function () {
        if (a == 0) {
                return false;
        }
        else if (a > 0){
                return max (a);
        }
        else {
                return min (a);
        }
}

// non-standard way
bool function () {
        if (a == 0) {
                return false;
        }
        if (a > 0) {
                return max (a);
        }
        return min (a);
}

---

It's obvious that the first way is easier to read and way better to do things
I am wondering if the second way would be faster once compiled, or not.

---

I'd say the first way is better.
In this particular case you have return statements in the if statements, so it wouldn't make much difference, but if you didn't return, the first method would skip all other else statements as soon as it finds one that evaluates to true, while the 2nd example would evaluate every if statement.

Quote:

---

Originally Posted by MacGyver

A smart compiler should be able to optimize either function to the same assembly code I believe.

---

Even a dumb compiler should. On the spectrum of the complexity of things which can be optimized, this sort of thing ranks about "0".

Quote:

---

Originally Posted by brewbuck

Even a dumb compiler should. On the spectrum of the complexity of things which can be optimized, this sort of thing ranks about "0".

---

Dumb compilers are usually termed such because they fail to achieve even standard compliance.... any optimizations by a dumb compiler would be shocking and somewhat above what we expect of them. :p

But on a serious note, I do get your point. :)

Quote:

---

Originally Posted by brewbuck

Even a dumb compiler should. On the spectrum of the complexity of things which can be optimized, this sort of thing ranks about "0".

---

I fully agree.
This is one of the easiest things a compiler can optimise.

Use whatever you prefer. It is not really a question of speed here, but a question of style.
The second listing can perhaps be more obvious that all control paths return values.

Quote:

---

Originally Posted by brewbuck

Even a dumb compiler should. On the spectrum of the complexity of things which can be optimized, this sort of thing ranks about "0".

---

As long as the compiler has a "optimize" option (that actually does ANYTHING), it should cope with that.

--
Mats

Quote:

---

This is one of the easiest things a compiler can optimise.

---

Not quite true. The easiest things to optimize are constant folding, instruction order optimization, instruction choice optimization, construct replacement (e.g. replace %2 with &1 where allowed), and similar optimizations. These have the property that they don't need instruction flow analysis. Instruction reordering needs a very simple form of data flow analysis.

This optimization needs control flow analysis. Granted, once you have that, this form of dead code removal is trivial, but first you need the analysis.