Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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-