Looping app cpu percentage

Hi,

When I ran a script application with a repeat loop and a delay of 3 seconds, it took up .4 to .5 % of the cpu. Is this a lot? I think it is.

Editted: Here’s the script:


set t to current date
set target_date to t + 60 * minutes
repeat
	if (current date) > target_date then
		exit repeat
	end if
	delay 3
end repeat
say "Goodbye"

Thanks,

Not compared with what delay has taken in some OS versions – in some cases it used to take 100% of a core.

I made a similar app (stay open) with an idle handler:


global target_date

on run
	set t to current date
	set target_date to t + 60 * minutes
end run

on idle
	if (current date) > target_date then quit
	return 3
end idle

on quit
	say "Goodbye"
	continue quit
end quit

Instead of the steady .5% cpu usage as the repeat loop, I get 0% when it’s idling (I think) and about .8% when it runs. I wonder which is better?

It seems like, If you have long idle times, then the idle handler is better.

Editted: am I thinking right?

Hi Shane,

Yeah, they did their job in finally changing it. I wonder why it stays steady at .5%. Does it use the Shell ‘sleep’. Haven’t tested that yet.

I suspect it uses Carbon’s Delay(), or did. In 10.6, and I think 10.7 – and possibly early 10.8 – it still took 100% CPU in ASObjC scripts. But I just did a quick test to confirm, and that seems to have been fixed too.

Hello.

I measured it at a point in time, and figured out that it is like shane states, that it now uses the system call nanosleep or something, and doesn’t perform “busy wait”, as it used to. So, I guess they changed it in Snow Leopard (10.6).

I retried it with a script like below, and there seemed to be no increase of the cpu-usage of Script Debugger. (I quit the script after a couple of seconds. Just to be sure, I repeated the experiment in AppleScript Editor,
and the results were coherent.


repeat with i from 1 to 1000
	delay 5
end repeat

I just tested the unix ‘sleep’ with python and it goes to 0%cpu usage when sleeping. Maybe the ‘delay’ command needs to think about other things. Unless I did something wrong with the python, but I don’t think so.

Thanks,

Should have posted the python script. There’s a lot of extra stuff, but I just wanted the script to keep running.


set py_text to "import time, os
cmd = 'sleep 3600'
start = time.time()
names = os.popen(cmd).read()
finish = time.time()
print finish - start
print names"
set py_text to ReplaceText(py_text, return, ASCII character 10)
set c to "python -c " & quoted form of py_text
set py_out to do shell script c
tell paragraphs of py_out
	set {t, file_list} to {item 1, rest}
end tell
--
on ReplaceText(t, s, r)
	set user_tid to AppleScript's text item delimiters
	set AppleScript's text item delimiters to s
	set temp_list to text items of t
	set AppleScript's text item delimiters to r
	set new_t to temp_list as string
	set AppleScript's text item delimiters to user_tid
	return new_t
end ReplaceText

kel

FYI: Not really, the sleep command in shell is an simple C tool that makes an system call to nanosleep. Delay in AppleScript is an event that will be send to eventually your scripting addition and there is with run some code that’s written in C too and probably call nanosleep too. So even if they’re not the same, they probably use the same system call.

An CPU usage of 5% isn’t much. AppleScript is maybe the easiest programming language to learn and write but it’s by far the most easiest to execute for an computer. In terms of processor usage it’s one of the heaviest programming languages there is.

Hi everybody,

Interesting stuff as always. The unix ‘sleep’ command showed some interesting things. When called from python, it uses 0% and when called with do shell script it uses from 0% to 0.1%.

Thanks a lot,
kel

:slight_smile:

Maybe Python “outsources” some work?

And for the record, cpu-usage isn’t everything, resource utilization, like memory is important as well.
We have both in quantity nowadays, but still, the lesser the number of pageswaps, the more efficient the system.
This is just a general statement, that memory usage also must be considered. And I have absolutely no formulae, save rule of thumb for what matters more, or when memory usage, would outrank cpu-usage.

Just for the record, Apple at least recommended that applications be compiled with optimization for size, and not speed, on a general basis, as that led to less page swapping, and thereby retained the best over all system performance. I don’t think you can manage to use that much resources for a sleep command anyway, so for the sleep command the cpu-usage maybe the governing factor. Any way, it is complicated math this, like a bar tab among old friends.

First of all this is an hardware issue, when developing AppleScript the least of your concerns should be hardware. Some of my machines have no page swaps at all :slight_smile: and some of them have an special SSD page swap device to run the machine more smoothly.

For those who doesn’t know what McUsr wrote: Page swaps is an mechanism that’s being used to store virtual memory on an secondary storage like an hard drive. In simple words, the less memory you have installed the more virtual memory will be used. This will slow down the instructions per second of the CPU and your CPU usage will go up :slight_smile:

Ironically it’s still the cpu-usage that’s the bottleneck

Hello.

I didn’t mean that kind of page swaps, I meant the kind of page swaps that happens when the cache is full, and some pages has to go, in order for others to come forward. I think page fault is a better term for that, than page swaps, and I’m sorry for the confusion.

A page fault is what happens, when the mmu (memory managment unit) can’t relocate a virtual address to a physical page in the cache, so it first has to take some page out, based on some algorithm, and then swap the virtual memory page (frame), into physical “hardwired memory”.

By the way, If you want to time do shell script commands, then the time command should do a very accurate job, showing the total (real time), and how much of that time was spent on the user side and system side of the OS.

By the way TN2124 is a great read!