Re: short-circuit control forms

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Thanks for the support. You pretty well summed it up.

*If* the timing is critical enough to be concerned about the efficiency of
short-circuit vs regular forms, then you *probably* want to make sure you
always execute the worst case scenario because you have not got the CPU to
spare if it doesn't work in the worst case.

In my mind, the only situation where this sort of really low level
optimization matters is the situation where you wouldn't want to be doing
this anyway. If you can afford the worst case, what does it gain you to do
the best case? Can you put those handful of spare CPU cycles to work
somewhere else on an "as available" task? The context switch would likely
eat more than what you saved.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Warren W. Gay VE3WWG" <ve3wwg@home.com> wrote in message
news:3B322AC5.2B8DC7B1@home.com...
> "Beard, Frank" wrote:
> > -----Original Message-----
> > From: Marin David Condic [mailto:marin.condic.auntie.spam@pacemicro.com]
> >
> > > Better to have the short-circuit things optional so you can manually
> > enable
> > > and disable the behavior as needed. Most of the time the extra
efficiency
> > is
> > > likely to be a) too small to sweat and b) not an issue because it
isn't a
> > > hard realtime system.
> >
> > Well, the argument could be made that if your second condition raised an
> > exception then your unit testing was insufficient (and yes I know unit
> > tests can't always catch everything).
>
> But Marin's point was that if you want to be closer to 100% sure that
> this piece of code will not raise an exception or blow the CPU budget,
> then you need to make sure that it is _always_ executed. Otherwise, you
> have to create the right kind of conditions to test that 0.01% -- which,
> might be near impossible without modifying the code (which itself
> invalidates the test). If I were flying on that code, then I'd want
> the AND to be used, and not the AND THEN clause. The object is to have
> greater confidence in the testing.
>
> > And as a general rule, it's a bad
> > idea to write functions with side effects, unless you have some glaring
> > necessity to do so.
>
> Nobody disagrees with this, but even functions without side-effects
> can create exceptions. That was the point. Also, it is possible for
> functions to have different CPU budgets, depending upon the inputs.
> This should be tested thoroughly.
>
> > Most, if not all, of the conditional statements that
> > I've written fall into the "and then" and "or else" category.
>
> I could see this in a non-critical piece of software. But where
> rigorous testing is involved, you will simplify your life by using
> the naked AND instead (where possible at least).
>
> > But as a point Marin has already made, I don't even worry about any of
> > these cases unless there is some runtime penalty.  In most cases, I
> > just use "and" and "or" because the code is cleaner looking.
>
> Coming from a C/C++ background, I tend to err on the side of
> short circuiting, but realize that this is not always wise. Even if
> you spend most of your life in business like, non-critical systems,
> you could end up writing re-usable code that may be applied differently
> than you imagined, by someone else.
>
> For this reason, you _should_ probably assume the worst case, as
> suggested by Marin, so that you don't inflict trouble on the next
> user of your code. The other benefit, as been pointed out, it is
> easier to test your code and gain greater confidence from your
> tests (greater path coverage).
>
> --
> Warren W. Gay VE3WWG
> http://members.home.net/ve3wwg