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 ****************************************
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
