Quick question

ID:1762077
 
Jan 13 2015, 7:46 pm
(See the best response by Kaiochao.)
Just a quick little question about efficiency.

if(!attacking&&!moving)



if(!attacking)
    if(!moving)


These two approaches obviously accomplish the same thing. My question is, is one more efficient in terms of saving CPU usage? My first thought is the second way is better because "moving" will only be evaluated if "attacking" returns false. This is just an example, I'm only wanting to know because I've always coded the first way, and I'm trying to improve my techniques

Jan 13 2015, 7:53 pm
Best response
Due to short-circuiting, they're equivalent. The !moving expression is only evaluated if !attacking passes.

I wouldn't say you're improving your techniques if you're worrying about something this insignificant. In general, you have worse things (CPU-wise) to consider.
Jan 13 2015, 8:00 pm
I was only asking because there are a lot of evaluations done in my melee subroutine, and that specific subroutine is called a lot. So I'm trying to optimize it in any possible way
Jan 13 2015, 8:13 pm
They're the same (barring any strangeness by the compiler).

In a long chain of booleans like this:
if(A && B && C && D && E && F)

if "A" is false, then the rest of the statement won't evaluate (doesn't need to: if A is false the statement cannot be true for any value of B/C/D/E/F). This is called boolean "short-circuiting", and it's a feature in most programming languages.

In general, this type of only-do-what-we-have-to behavior is called "lazy evaluation" (google that for more info). Some languages like Haskell even encourage you to do nutty things like this:
A ? B : \
C ? D : \
E ? F : \
G ? H : \
...
//on to infinity or limit

via expansion: if the chain eventually terminates (one of the conditionals is eventually true) then the next statements are not only not evaluated, they're not even compiled: which in this case wouldn't even be possible!



Jan 13 2015, 8:16 pm
I see. I appreciate the explanation ^.^