Most Efficient Timer?

[Dar Scott]

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 communications apps would need much better than 1 second 
timing, of course.  Some games might, too.

> Bear in mind that if running these tests in the dev environment, some 
> of that percentage will be due to added overhead of the development 
> environment.  You should likely test this with standalone apps to get 
> a more meaningful measurement.

That's a good test.

However, I'm now getting 0% without the send cycle.  Also, I'm not sure 
what the dev environment would do but add maybe 20 ns each cycle as the 
message rattles down the front scripts before getting to the right 
script.

It might be all that overhead is in the event queue overhead, but I 
would be surprised if it was.

> I created a new mainstack and saved it, then saved it as a standalone 
> (no objects or scripts).  Now I run the 'time' command on this 
> standalone:
>
> real    0m47.594s
> user    0m0.530s
> sys     0m0.250s
>
> This would be 0.78 second over 47.594 seconds, or 1.64% CPU usage -- 
> with *NO OBJECTS OR SCRIPTS*.
>
> This time is likely taken up by the Rev engine, so it would seem that 
> the actual CPU usage of my little checkbox mechanism is only about 
> 2.34 - 1.64 = 0.7% CPU usage.  Hmm....

.7% of 47.594 s is .333158 s
47.594 s / 5 s per cycle is 9 cycles
.333158 s / 9 cycles

That means an overhead of 37 ms per cycle.

That's the bad news.

The good news helps a little.  In applications with more than 25 
messages per second, several are done in a row, otherwise the message 
queue would grow indefinitely.

Even so, I think this is an awful overhead.  I want 1.1 ms or better.

I think I've made my point here.  ;-)

> Do note that these percentages will likely decrease slightly with 
> longer runtimes (flattening out because of startup time, 
> initialization, etc.), but I have no reason to run the tests for that 
> long, I think I made my point here.

****************************************
     Dar Scott Consulting
     http://www.swcp.com/dsc/
     Programming Services
****************************************


****************************************
     Dar Scott Consulting
     http://www.swcp.com/dsc/
     Programming Services
****************************************