OpenEuphoria

and...and...and

• Posted by Robert Craig <rds at CLASSIC.MSN.COM> Sep 15, 1997
• 2608 views

Einar Mogen writes:
> Then, I discovered something about speed last night. This could be old news
for
> all you, but of these two "if's":

> if ... and ... and ... and ... then
>        <...>
> end if

> if ... then
>        if ... then
>                if ... then
>                        if ... then
>                                <...>
>                        end if
>                end if
>        end if
> end if

> -the last one is the fastest. Shouldn't Euphoria just skip the rest of an
"if
> ... and" line if the first part checks false? It seems to me that all parts
of
> an "if ... and ... and" line is checked each time, which did result in a
> slowdown in my game.

You are correct. Euphoria does not do "short-circuit" evaluation of and/or/not
conditions.
I have this on my list of desirable features, but it might not happen for a
while,
if at all, because:

   1. It's hard to retrofit this in to ex.exe.

   2. It would break some people's existing code (only a tiny percentage I
would guess)
       in the case where there are side effects from evaluation (e.g. function
call sets a global variable)

   3. Euphoria's conditional expressions can involve sequences, as well as
atoms. e.g.
      if A and B then ..., where A is 1 and B is {0,1,2} is supposed to
evaluate to {0,1,1}
      which is supposed to cause an error when used in an if statement. We'd
have to
      accept A and B as being "true" without any error message.

> Do the rest of you know of other "trivial things" which could have a
> major impact on speed?

In Euphoria there are a surprising number (even to me)
of trivial things that can affect performance. This is generally due to the
fact that Euphoria does not map directly to machine code the way C does.
The Euphoria interpreter is doing "invisible" things, such as storage
allocation,
in order to give you a simple, safe, flexible world to program in.

Fortunately, in Euphoria you have the ability to profile your code using:

      with profile
or
      with profile_time

If you care about performance you really should profile
your code at least once. Do not assume that you "know" which
sections of code are consuming most of the time. You will *often*
be surprised.

You can also time small sections of code using:

     atom t
     t = time()
     for i = 1 to 1000000 do
         -- your code goes here
     end for
     ?(time()-t)/1000000

Regards,
   Rob Craig
   Rapid Deployment Software