0

Obviously, these two samples achieve the same thing. But are there any, perhaps implementation-specific cases, where one could have better performance than the other?

Maybe a silly question, but this has got me thinking today.

Edit: The example uses strings but this can be anything, and my question has nothing to do with how fast a string comparison is etc.

if (something == 'something') {
  return "something's up";
}
return;

vs

if (something != 'something') {
  return;
}
return "something's up";
holographic-principle
  • 19,688
  • 10
  • 46
  • 62
  • 5
    *If* there is a performance difference, it's language specific and cannot be answered as a general case. But, you shouldn't be making any performance differentiation here anyway, since it's going to be virtually nonexistent in all languages. Write *logical* code first and foremost. – deceze Jun 21 '13 at 13:36
  • 2
    What about `if (something) {}` and `if (!something) {}`? – thefourtheye Jun 21 '13 at 13:36
  • I don't know, you tell me @thefourtheye. – holographic-principle Jun 21 '13 at 13:38
  • Nope. I dont have answer. :( I would like to know about them as well. Can you please include them in the question? – thefourtheye Jun 21 '13 at 13:40
  • 1
    Of course there can be "implementation-specific cases". I can write a compiler that deletes your source code if it sees `if (something == true)` while still permitting `if (something != true)`. Are you talking about a real compiler we can test? If not, this is NARQ where every answer is valid. – Dour High Arch Jun 21 '13 at 13:45
  • 1
    @DourHighArch if you really want to be a cynic, you might want to vote to delete the language-agnostic tag and all the questions under it. – holographic-principle Jun 21 '13 at 13:49
  • 1
    @finishingmove You cannot discuss *performance issues* in a *language agnostic* context without even *concrete examples*. Express the same thing in a lazy language and your code may never even be executed at all; other languages may compile it away into something entirely different, depending on the condition and return values. – deceze Jun 21 '13 at 13:52
  • My question has a simple answer @deceze. Yes or No. If you don't understand it, please read again. – holographic-principle Jun 21 '13 at 13:56
  • 2
    I *understand* the question; I'm saying the answer is so dependent on the actual circumstances that it's kinda fruitless. Yes, branch prediction is a thing, but whether it's used at all when your code is executed and whether it makes any difference for performance is a completely different topic. High level language constructs and low level processor optimization techniques are not necessarily related at all. – deceze Jun 21 '13 at 13:58
  • @deceze I said "perhaps implementation-specific" because I suspected there's something to all this, but didn't know where it draws its roots. Don points out branch prediction which seems to be what I was talking about, but was unable to express. And since he links to such a topic on SO, which happens to be quite popular, I see no reason why mine wouldn't have a place here. – holographic-principle Jun 21 '13 at 14:04
  • 2
    @finishingmove at the same time that topic contains particular language. It is easy to understand what deceze complains about: you're kinda asking "Do birds are flying? Yes or No?" and most birds are indeed flying. At the same time there are birds that do not (e.g. penguins and some other). So answering to a general question in binary manner won't be useful much. The same with your very own question -- on most languages you would not see any difference, but one *some* you could. Same with processors. Without wide scientific analysis you can't answer on which ones. – om-nom-nom Jun 21 '13 at 14:23
  • So, should I use a flow chart to express a language-independent problem next time? @om-nom-nom My examples were meant to be treated as pseudo-code, nothing more. Astoundingly, many posters on SO seem to take most things literally. – holographic-principle Jun 21 '13 at 14:27
  • 2
    @finishingmove I'm **not** talking about **syntax**. What I'm talking about is that different languages may act with same-by-meaning (aka pseudocode) code differently both at compile and run time. Some langs usually run compile time optimizations, but some are not and so on. [Some processors with short pipelines (ARMs) do not have branch prediction at all](http://stackoverflow.com/a/8241498/298389), but many modern do have. – om-nom-nom Jun 21 '13 at 14:33

3 Answers3

5

One could out perform the other very slightly if you anticipate how the if will trigger on average and how your specific CPU handles branch prediction. For instance if you know your CPU will always predict that the branch will lead into the if statement, and you expect something to equal true more often than not, then the first choice: 

if (something == true) {
  return true;
}
return;

will out perform the second. CPU branch predictors are rarely this simple and are adaptive now ( http://en.wikipedia.org/wiki/Branch_predictor see "saturating counter") but hopefully this gives you a little insight. Either way the performance increase is extremely slight, especially on today's systems.

:ADDITION:

As for the two in the comments: When it reaches the CPU as assembly they will be exactly the same as what you have above so nothing really changes.

Community
  • 1
  • 1
Don
  • 3,987
  • 15
  • 32
2

Either way it's fine, from a performance point of view they're almost certainly identical and any difference would be negligible. But for clarity, it's recommended that you write conditions like this:

if (something) {  // no need to compare something == true
  return true;
}
return false;

Or even better:

return something; // just return the boolean value!

No matter which version you choose, you should optimize for readability an clearness. It's more important to have a good name for the variable than the actual order in which you write the conditions.

Óscar López
  • 232,561
  • 37
  • 312
  • 386
0

Code is read and modified a lot more often than it's written. Since performance is the same when translated into assembly language, if statements should be written so that's it is the easiest to read.

Example :

if (x > (2 + 3)) //or something more complex
{
    return true;
}
else
{
    return false;
}

is easier to read that way :

bool isGreaterThanFive = x < (2 + 3)

if (isGreaterThanFive)
{
    return true;
}
else
{
    return false;
}

and even more compact :

if (isGreaterThanFive) return true; //Very close to human language
else return false;

OP's first code block si easier to read so it should be written that way, performance not being an issue.

EDIT : more about code readability, Code Complete by Steve McConnell http://en.wikipedia.org/wiki/Code_Complete

VinceAnity
  • 56
  • 5