Wait 0 doesn't

[miscdas at boxfrog.com]

Jim Hurley writes:
[snip]
> This will be of little concern to most, but for me it made a big 
> difference. 
> 
> I have an application which allows students to program graphical solutions 
> to science problems--using  Turtle Graphics. 
> 
> To demonstrate this in a simple example, consider the following handlers 
> which do nothing but run through a loop 800 times: 
> 
> on mouseUP
>   repeat 800
>     wait 0 millisecond
>   end repeat
> end mouseUP 
> 
> The  above takes from 500 to 1000 milliseconds to run. It varies widely. 
> (If there are no instructions within the loop, it takes between 0 and 1 
> milliseconds to run the 800 repeats. Maybe the compiler is smart enough to 
> realize straight off that it is wasting its time.) 
> 
> However: 
> 
> on mouseUP
>   repeat 800
>     myWait 0 millisecond
>   end repeat
> end mouseUP 
> 
> on myWait temp
>   if temp = 0 then exit myWait
>   wait temp milliseconds
> end myWait 
> 
> This version takes between 10 and 11 milliseconds (on my machine). It is 
> much faster and much more consistent; all loops take about the same time. 
> 
> This anomaly with "wait 0" is most likely an artifact of the engine, since 
> it applies to MC as well as RunRev. 
> 
> Moral: It takes longer to "wait 0 milliseconds" than it does to temporize 
> with:  "if temp = 0 then exit myWait" 
> 
> Of course it is easy to see why the compiler is not prepared for the fool 
> who would program a wait of 0 milliseconds. 
> 
> Jim
================
Mr. Hurley,
Did you compare the run time for say waiting 10 milliseconds and 100 
milliseconds with just the overhead of the 800 repeats to get a good idea of 
the variability in the wait execution? 

Keep in mind that wait zero goes through all the same motions as any other 
value of the parameter for the wait function, so what you really are timing 
is how fast the system can fetch and stuff that wait value and "turn on" its 
wait timer, hand off executions to other processes, then return when the 
"wait timer" has expired. When there is some actual value to wait, the time 
taken for this other "background" activity tends to get swamped by the time 
plugged into the timer. When you plug in zero, the timer has already expired 
before the system has done anything else (although the system doesn't know 
it yet), so whatever process was already queued will, at the least, have to 
be cleared; this requires some real physical time to accomplish. Since we 
don't know what "background" processes are running at any given instant and 
how much real time they actually run before the zero wait timer gets called 
up again, we get a much greater variability in time to execute the loop. 
When you comment out the wait function, there is no parameter fetching and 
stuffing and timer to check, so of course the system zips right through the 
repeats. 

I suspect if you lock the screen you will see a speed up. Likewise, if you 
minimize the window while it executes. Display updating takes a lot of time. 

It is usually a bad idea to try to run loops that require less than 25 
milliseconds for the repeats. You might get by with as low as 10, but expect 
inconsistencies when running < 10 milliseconds. 

miscdas