Most Efficient Timer?

[Richard Gaskin]

Scott Rossi wrote:
> I've been thinking about timers recently and thought I run this by the list
> to see what other Rev experts thought.  I guess the way to set this is up
> is: "Can you script a more efficient timer?"
> 
> ----------
> 
> The way I usually build asynchronous timers uses a "send in" structure like
> the following: (simplified for example)
> 
> local tCurrTime
> on runTimer
>   if not the uAllowTimer of me then exit runTimer
>   if (the millisecs > tCurrTime + 1000) then
>     put the millisecs into tCurrTime
>     put the long time into fld 1
>   end if
>   send "runTimer" to me in 100 millisecs
> end runTimer
> 
> The above example checks the value of the milliseconds 10 times a second and
> puts the result into a locked field after one second has elapsed.  But it
> also generates 10 messages a second, and it occurred to me that another way
> to do this is to use the "wait x with messages" construct which I'm guessing
> evaluates time many more times a second, but at a lower level than "send
> in":
> 
> local tCurrTime
> on runTimer
>   repeat forever
>     if not the uAllowTimer of me then exit runTimer
>     wait until (the millisecs > tCurrTime + 1000) or \
>         (not the uAllowTimer of me) with messages
>     put the millisecs into tCurrTime
>     put the long time into fld 1
>   end repeat
> end runTimer
> 
> Both of the above routines provide the same output.  However, when viewing
> the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
> clearly dependent on the frequency of the "send in" message: with 100
> milliseconds frequency, the first handler runs at about 15% usage, and with
> 50 milliseconds frequency runs at about 30% usage (makes sense).
> 
> Amazingly, the "wait x with messages" handler runs at less than 1% usage.
> And because "with messages" does not block other messages from being sent,
> this seems a very efficient way to run a timer.
> 
> Obviously the above is useful only in situations requiring accuracy of 1
> second or less, but at first glance I can't see any drawback to using this
> method.  Can you?

None that I can see, but I managed to get myself confused on the issue: 
  if you only want a time sent once a second, why not just send it in 1 
second rather than polling several times a second?

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev