>I haven't saved the original message this applies to, so imagine this as a revisit to the old thread (a week or two ago).
>
>Someone here played with an example trying to prove that
>
>if [expression]
>else
> [any stuff here]
>endif
>
>is faster than
>
>if not [expression]
> [any stuff here]
>endif
>
>...because the NOT operator works on some arithmetics, and the if-else construction simply jumps to the next statement. Theoretically I've almost agreed to that, since NOT does need some (albeit trivial) computing, but the example he gave sounded somewhat strange - I didn't see the statement tested iterated in innermost loop, it was laid some other way round. Not being sure I have followed the idea properly, and having lost track of the original message, I've written this:
>
>store seco() to t1
>store 0 to aa
>for i=1 to 1000000
> x=(i%2)=1
> if x
> else
> aa=aa+1
> endif
>endfor
>?seco()-t1, "if else"
>
>
>store seco() to t1
>store 0 to aa
>for i=1 to 1000000
> x=(i%2)=1
> if !x
> aa=aa+1
> endif
>endfor
>?seco()-t1, "if not"
>
>The results are somewhat surprising - the other way is faster by a wee half percent or less, but it is always mesurably faster (on my machine, something like 12.82 seconds vs 12.08 or so). I've ran several versions of this test, including some with random numbers (used x=rand()>0.5, and =rand(43) before the loop, so x was false equal number of times) etc, but the ratio remained substantially the same.
>
>The only explanation to this is that, though the NOT operator involves some arithmetics, its overhead is somewhat less than the overhead for processing one extra statement - the ELSE.

Hi Dragan,

Interesting stuff. However, you know I'll always come down on the side of readability here.:-)

It does bring to mind the following, but I'm not totally sure that it would still apply. This is from something I read sometime ago. In constructing an IF < lexpr1> OR < lexpr2 >, it's a good idea to place the condition that evaluates to .T. (if known) the greater amount of times first. This is because, the second condition only is evaluated when the first is .F. Placing the lesser condition first will require a greater number of comparisons of both expressions.

Like I said, this was sometime ago, so I don't know (and haven't tested) if it still applies. I believe, however, that it probably does.