Re: short-circuit control forms

[Ted Dennison<dennison@telepath.com>]

In article <3B30F836.D700DAA3@raytheon.com>, James A. Krzyzanowski says...
>If using "and then" and "or else" will make our software quicker, and
>then the compiler doesn't optimize any better anyway, does anybody have
>a good reason why we should NOT use short-circuit control forms?

First off, its *not* assured that it will always be quicker. Since you are
replacing one branch with one branch for each condition, it will actually result
in *more* instructions being executed if it turns out that all the conditions
need to be applied. Depending on how many conditions there are and how much work
calculating them all is, in some cases the non-short-circuit form will execute
less code even when not all of the conditions are executed.

Another thing you have to consider is that most modern processors have a branch
prediction unit (BPU) that will do speculative execution to keep the instruction
pipeline filled when branches are encountered. If the "speculation" is
incorrect, the entire pipeline has to be flushed, which slows things down
greatly. Short-circuit forms generate more branch instructions, which can amount
to more chances for the BPU to guess wrong. Again, this may be trivial compared
to the chance of not executing a lot of extra code. But if the code in
calculating the conditions is small, or its usually all executed, then it can
matter.

Another important issue is maintanence. When someone unfamiliar with that code
first tries to read it, they are probably going to expect that there's some
*reason* that those short-circuit forms had to be used, and that there's some
reason that the conditionals are in the order they are in. As an example of a
problem that could cause, suppose one conditional needs to be split out for some
reason. That may lead to unnessecary complication of the code to preserve that
(presumed-important) ordering.

My last argument against this approach is philosophical, but relates directly to
all my previous points. As a general rule, you do *not* go about randomly
optimizing code, at the expense of complexity or readability. Programs generally
do not have their workload spread out evenly over the source, so this is an
incredibly bad use of man-hours (on both ends). The proper way to optimize is to
find a part that is running too slowly, find the slowest part of that, and see
what you can do to speed it up (then repeat until satisfied). Hand-optimization
should be done with tweezers and a microsope, not with a blindfold and a
sledgehammer. 

So unless there is some *verified* speed problem with a particular conditional,
write it the way in which it makes the most sense.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com