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:
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
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
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
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
On 29 Nov 2004, at 14:47, Geoff Canyon wrote:
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
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
Scott Rossi wrote:
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
This helps to avoid another problem as well. If a one-second timer is
started at, say, 1:31:32, then the minute will be about half-over by
the time the display is updated, so that the time display is only
accurate about half of the time.
Of course, the timer may drift somewhat if there is a
At 13:33 29/11/2004 -0500, Frank D. Engel, Jr. wrote:
This helps to avoid another problem as well. If a one-second timer is
started at, say, 1:31:32, then the minute will be about half-over by the
time the display is updated, so that the time display is only accurate
about half of the time.
On Nov 29, 2004, at 1:00 AM, Scott Rossi wrote:
Can you script a more efficient timer?
Here are some overhead times on my system:
Time to send in time: 10 ns
Time to use an empty custom command:34 ns
Time to process an _additional_ empty pending
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
Recently, Dar Scott wrote:
Can you script a more efficient timer?
Here are some overhead times on my system:
Time to send in time: 10 ns
Time to use an empty custom command:34 ns
Time to process an _additional_ empty pending message:
Recently, Scott Rossi wrote:
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
On Nov 29, 2004, at 12:36 PM, Scott Rossi wrote:
It looks to me that using send in time is efficient.
Actually, I was referring to efficiency in terms of placing demands
on the
system, not in the amount of time to process within Rev.
Oh, I see what you mean. I used Activity Monitor on OS X and
With send times that short, I would not be too worried about most of
those readings. The 2% usage for a 1 second timing is a bit more
meaningful, and even this is not too bad (though I suspect it could be
better).
Bear in mind that if running these tests in the dev environment, some
of that
On Nov 29, 2004, at 2:53 PM, Frank D. Engel, Jr. wrote:
With send times that short, I would not be too worried about most of
those readings. The 2% usage for a 1 second timing is a bit more
meaningful, and even this is not too bad (though I suspect it could be
better).
Many types of
17 matches
Mail list logo
