Most Efficient Timer?
Scott Rossi
scott at tactilemedia.com
Mon Nov 29 03:00:50 EST 2004
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?
Regards,
Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
E: scott at tactilemedia.com
W: http://www.tactilemedia.com
More information about the use-livecode
mailing list