Most Efficient Timer?

[Geoff Canyon]

On Nov 29, 2004, at 3:56 AM, Richard Gaskin wrote:

> Dave Cragg wrote:
>> On 29 Nov 2004, at 09:11, Richard Gaskin wrote:
>>> Scott Rossi wrote:
>>>> 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?
>>>
>> 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?

Anything that's going to stop a 1 second message is also going to stop 
a 1/10 second message as well. It's possible I suppose for send...in to 
take slightly longer than a second, so when a visible display is 
ticking over I generally use something like 55 ticks, which should 
(virtually) guarantee that it will tick over.

wait...with messages is perfectly fine to use. The one that hogs the 
system is when you wait for a system condition to change: wait until 
the mouse is up, repeat while the mouse is down, that sort of thing. 
Even then it's okay if you're actually _doing_ something. The problem 
enters in when you have something like

repeat while the mouse is "down"
   set the loc of me to the mouseLoc
end repeat

The problem here is that as fast as the system is able you're setting 
the loc of the object to the exact same value (because most of the time 
the mouse isn't moving).

Specifically, there is nothing wrong with wait 55 ticks with messages.

Further, you will still see a responsive system with wait 0 ticks with 
messages. In that video game I programmed a year back, I have a delay 
loop to keep the game from running too fast on very fast systems. It 
keeps track of how long it needs to wait to update the screen. On 
slower systems, that value can decrease to 0, or even -1 or -3, so the 
code executed is

wait -3 ticks with messages

It still works.

regards,

Geoff Canyon
gcanyon at inspiredlogic.com