wait 0 doesn't
jhurley at infostations.com
Tue Apr 29 11:17:00 EDT 2003
>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
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:
if temp = 0 then exit myWait
wait 0 ticks
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.
More information about the use-livecode