wait 0 doesn't

[Jim Hurley]

>
>================
>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.


Good point. There is a great deal of variability regardless of the  wait time.

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


I can't lock the screen since it is important for the students to be 
able to see the *evolution* of the motion on the screen. But I can 
solve my problem by redefining the "wait" handler as follows:

myWait temp
   if temp = 0 then exit myWait
   wait 0 ticks
end myWait

This does not have the variability of the built-in wait 0. In those 
problems where the wait time is greater than zero (for example 
drawing a polygon--too fast to see the steps without waiting between 
steps), the program execution is very short and so memory doesn't 
becomes swamped--execution is smooth. And in those problems when the 
wait time is 0 (for example drawing a planetary orbit--several 
hundred short steps), the memory doesn't becomes swamped with myWait 
which simply exits the handler--again the execution is smooth.

Jim