Does the order of expression to check in boolean statement affect performance

If I have a Boolean expression to check

(A && B)

If A is found to be false will the language bother to check B? Does this vary from language to language?

The reason I ask is that I'm wondering if it's the case that B is che开发者_开发百科cked even if A is false then wouldn't

if (A) {
  if(B) {

  } else {
     // code x
  }
} else {
  // code x
}

be marginally quicker than

if (A && B) {

} else {
   // code x
}

This depends on the language. Most languages will implement A && B as a short-circuit operator, meaning that if A evaluates to false, B will never be evaluated. There's a detailed list on Wikipedia.

Almost every language implements something called short-circuit evaluation, which means that yes, (A && B) will not evaluate B if A is false. This also takes effect if you write:

if (A || B) {
    ...
}

and A is true. This is worth remembering if B may take a long time to load, but generally it's not something to worry about.

As a bit of history, in my mind this is a bit of a sore part of LISP because code like this:

(if (and (= x 5) (my-expensive-query y)) "Yes" "No")

is not made of functions, but rather so-called "special forms" (that is, "and" could not be defun'd here).

This would depend 100% on how the language compiles said code. Anything is possible :)

Is there a specific language you're wondering about?

In short, no. A double branch involves various forms of branch prediction. If A and B are simple to evaluate, it may be faster to do if (A && B) in a non-short-circuit way than if (A) if (B). In addition, you've duplicated code in the second form. This is virtually always (exception to every rule .. I guess) bad and far worse than any gain.

Secondly, this is the kind of micro-optimization that you give to the language interpreter, JIT or compiler.

Many languages (including almost all curly-brace languages, like C/C++/Java/C#) offer short-circuit boolean evaluation. In those languages, if A is false then B won't be evaluated. You'll need to see (or ask) whether this is true for your specific language, or whether there's a way to do it (VB has AndAlso, for example).

If you find your language doesn't support it, you'll also need to consider whether the cost of evaluating B is worth having to maintain two identical pieces of code -- and the potential doubling in cache footprint (not to mention all the extra branching) that'd come from doing that duplication every time.

As others have said, it depends on the language and/or compiler. For me, I don't care how fast or slow it might be to short-circuit or not, the need to duplicate code is a deal-killer.

If A and B are actually calls that have side-effects (i.e. they do more than simply return a value suitable for comparison), then I would argue that those calls should be made into variable assignments that are then used in your comparison. It doesn't matter whether or not you always require those side-effects or only require them conditionally, the code will be more readable if you don't depend on whether or not short-circuit exists.

That last bit about readability is based on my feeling that reducing the need to refer to external documentation improves readability. Reading a book with a bunch of new words that require dictionary look-ups is much more challenging than reading that same book when you already have the necessary vocabulary. In this case, short-circuit is invisible, so anybody that needs to look it up won't even know that they need to look it up.