[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
> loop
> 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
> much
> faster than putting another upper-limit test inside a pre-test loop.
>
> -jn-
>
> -- To unsubscribe from this list, please send an email to
> [rebol-request--rebol--com] with "unsubscribe" in the subject, without the
> quotes.
>
Using the following dinky timing function:
race: func [end [number!] /local op start bump old t0 t1 t2][
op: :greater-or-equal?
bump: 1
start: 1
t0: now/time/precise
while [op end start] [start: start + bump]
t1: now/time/precise - t0
start: 1
t0: now/time/precise
until [
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
0:00:30.222434 0:00:25.854029
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.)
-jn-
