Shell or Applescript: processor efficiency

[sinjin]

I'm using GeekTool to display iTunes info on my desktop based on comments to a posted hint:

http://www.macosxhints.com/article.php?story=2004070301135736

My question is, is it more efficient (less processor intensive) to use a shell script wrapper to check if iTunes in running before running the Applescript to get iTunes info OR to go purely with Applescript to do the same thing. For those unfamiliar with GeekTool, essentially what is going to happen is it is will run these scripts at a repeating interval (probably 10 s). Examples follow:

Shell version (note, pasted as original author wrote it, with my comments:

#!/bin/sh
app=$1 #I guess I set this to iTunes
scpt=$2 #I guess I set this to the path of my Applescript
if [[ -n "`ps -x | grep /Applications/${app}.app | grep -v grep`" ]]; then
osascript $scpt | iconv -f utf-8 -t ucs-2-internal
fi

Or Applescript:

tell application "System Events"
if process "iTunes" exists then
--the rest of the script goes here
end if
end tell

Thanks! Mark

[hayne]

I think the relative efficiency depends on the probability that iTunes is running. If iTunes is not running, the shell version will determine that and exit relatively quickly compared to the pure AppleScript version (which will take a relatively long time just to start up).
But if iTunes is running, the shell version is probably less efficient since it starts 3 separate processes (ps, grep, grep) only to determine that it should go ahead. I presume that AppleScript's "if process ... exists" is more efficient than that.

Why not try both versions (run both at once), monitor their CPU usage with 'top' or "Activity Monitor" and determine the answer empirically?

[sinjin]

I didn't even think to consider the shell script calls multiple processes! I'm such a noob. I guess I was expecting a blanket generalization Like "Applescript is horribly inefficient" or otherwise.

Why not try both versions (run both at once), monitor their CPU usage with 'top' or "Activity Monitor" and determine the answer empirically?
Great advice. I'll give it a try.

Thanks much!

[robJ]

I think the relative efficiency depends on the probability that iTunes is running. If iTunes is not running, the shell version will determine that and exit relatively quickly compared to the pure AppleScript version (which will take a relatively long time just to start up).

If the AppleScript script is saved and run as an application then I agree with hayne, because the app's launch time will slow it down. If the script is being executed in compiled form (not saved as an application) by running it from a script menu, then I suspect that it's more efficient than the shell script.

-- Rob

[acme.mail.order]

the shell script calls multiple processes

sure, but each process is small, compiled in machine code, and very fast. Timing a similar process on my machine showed a total time of 0.04 seconds. Today's machines are fast enough that for most daily utilitarian purposes you don't need to consider performance much. (I don't consider processor-hog programs like AV recoding and sorting a 50k-line database in this category)

Short answer: don't worry about it too much - do whatever's easier to program or you'll spend hours of your time trying to save milliseconds of processor time. I like shell solutions mainly because I've found scheduled execution more reliable in the shell, but it also splits your program up and makes it a little harder to install.