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.
On a 500MHz G4 (OS 10.3.6), I created a new mainstack with a single checkbox. The checkbox script is:
on x send "x" to me in 1 second set the hilite of me to not the hilite of me end x
And the mainstack script:
on openStack send "x" to button "Check" in 1 second end openStack
I then saved this and saved it as a standalone. Activity monitor (updating every 2 sec) reports:
The Rev IDE with the stack open (and no others): keeps shifting between 0.5%, 1%, 1.9%, 2%...
The standalone app: about the same, except that it occasionally drops as low as 0.4%, and I did see *one* flash of 3%.
Now changing the update interval to 0.5 sec:
CPU usage actually flashes from *zero* to as high as nearly 5%.
Now changing the update interval to 5 sec:
CPU usage switches from zero to about 1.9 or 2 percent.
Hint: most of the time (CPU perspective) the usage is zero. When updating the checkbox, the usage can jump to as high as nearly 5% for a brief period of time. My guess is that the activity monitor is biased toward giving the higher readings.
I used the command-line 'time' utility to measure the runtime of the standalone. The results after a few seconds were:
real 0m14.617s user 0m0.890s sys 0m0.230s
Combining user with system CPU time of the process yields about 1.12 seconds, out of 14.617 seconds that the process was running. This would suggest about 7.7% CPU usage. Bear in mind that this includes startup time, displaying the window, initializing the engine, etc.
Now after a somewhat longer run:
real 1m6.203s user 0m1.200s sys 0m0.350s
This suggests usage of 1.55 second over the course of 66.203 seconds, for about 2.34% CPU usage. Notice that this is much lower, and this is likely due to the fact that much of the startup time, etc. from the runs is a "one-time" issue.
Next experiment:
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....
You can't always judge a book by its cover.
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.
On Nov 29, 2004, at 3:38 PM, Dar Scott wrote:
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 got this:
Send cycle (.1 s period): 16% Default Button: 29% Both: 35%
Send cycle (.05 s period) 35% (fluctuates a lot) Send cycle (.01 s period) 101% Send cycle (1 s period) 2%
I'm on OS X 10.3.6 using a dual 1.25 GHz G4.
Dar **************************************** Dar Scott Consulting http://www.swcp.com/dsc/ Programming Services ****************************************
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
----------------------------------------------------------- Frank D. Engel, Jr. <[EMAIL PROTECTED]>
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.
$
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
