Most Efficient Timer?

Scott Rossi scott at
Mon Nov 29 13:28:08 CST 2004

Recently, Richard Gaskin wrote:

>>>> I guess Scott was concerned about the smoothness of the time display
>>>> ticking over. If you send every 1 second, and there is something holding
>>>> up message processing, the timer may be late to update. Increasing the
>>>> frequency increases the chance of getting it right (but doesn't
>>>> guarantee it).
>>> Wouldn't any issues that would delay the firing of a one-second timer
>>> also delay a 1/10th second timer as well?
>> It could, but if one is after one second accuracy, for example, the
>> one-second timer will be thrown off, whereas the 1/10-second timer has the
>> opportunity to correct itself (assuming whatever issues delay the timer
>> don't take 3 seconds to execute).
> If a message were completely removed from the queue that would be an
> issue.  But if the message is merely delayed until the next idle,
> wouldn't all messages that are due for firing get fired in their firing
> order, regardless of the wait period specified when they were queued?

I don't quite follow what you're asking here (like Dave, my brain is
starting to ache), but it prompted me to try something else:

on runTimer
  if not the uAllowTimer of me then exit runTimer
  send "runTimer" to me in 100 millisecs
  put the long time into fld 1
end runTimer

This handler immediately triggers itself again before doing anything, so in
theory, it should remain relatively consistent while being called only once
per second.  However, taking a look at the CPU usage shows this simple
routine runs around 14% to 15% or so processor usage.  The "wait x with
messages" apparently uses next to nothing.  So while efficient script-wise,
"send in" appears to require significant more engine power to run.  That's
my take on this anyway without knowing the details about Rev's inner

You may say "what's the big deal about 15% CPU usage?"  It may not be an
issue for many folks.  In my case, it is a big deal: moving images around a
card, swapping the icons of buttons, scrolling text in fields, all this
stuff adds up and places higher demands on the engine.  Anything I can do to
reduce these demands enhances the ability of my apps to play nice with

FWIW, I've come across other things that contribute to CPU use.  From the
above, running a timer and updating the time in an unlocked field requires
about 4 to 5 times as much usage as when placing text in a locked field.
Locking the screen before updating a number on on-screen items can place
very high demands on CPU usage if done frequently.  You may recall the
jukebox project I posted some time ago -- I consistently ran into memory
problems when trying to move all those bubbles around the screen.  I tried
everything I could of the get the processor use down and on a whim tried
removing the "lock screen" instructions from my scripts.  Not only did
processor use become manageable but Rev was fast enough to update the 25 or
so images without major delay.  This may not work for all situations but
it's a good trick to keep in mind.


Scott Rossi
Creative Director
Tactile Media, Development & Design
E: scott at

More information about the use-livecode mailing list