[REBOL] Re: for bug?
From: joel:neely:fedex at: 17-Jun-2002 12:36
Just a bit more detail... (I'm multitasking furiously this week ;-)
On Monday, June 17, 2002, at 11:36 AM, Joel Neely wrote:
> Hi, Romano,
> On Monday, June 17, 2002, at 10:26 AM, Romano Paolo Tenca wrote:
>> Joel, i do not understand your for code, is missing something?
>> if op end start [
>> until [
>> start: (old: start) + bump
> What's missing is the working part of the loop body. I stripped the
> down to just the "counter" management to see what would happen to the
> overhead timing in going to post-test.
> I think that a single range test wrapped around the post-test loop is
> faster than putting another upper-limit test inside a pre-test loop.
> -- To unsubscribe from this list, please send an email to
> [rebol-request--rebol--com] with "unsubscribe" in the subject, without the
Using the following dinky timing function:
race: func [end [number!] /local op start bump old t0 t1 t2][
while [op end start] [start: start + bump]
t1: now/time/precise - t0
start: (old: start) + bump
op old end
t2: now/time/precise - t0
print [t1 t2]
which implements the pre- and post-test loops with no actual processing
inside the body, I get
>> race 5000000
which shows that we could pick up about an 11% performance improvement by
having UNTIL rather than WHILE as the working part of FOR as Romano has
suggested. (Notice that I didn't bother to wrap UNTIL in the IF pre-test
since that's a one-shot cost.)