| There are people who worry about squeezing every last possible ounce of speed out of AppleScript. They like nothing better than to sit down with a script and find clever ways of rearranging or reexpressing it so as to make it run faster. They have developed ingenious tricks and devices to optimize AppleScript code for speed. They even hold little contests to see whose script can complete a given task fastest! Personally, I'm not a great believer in optimizing code, but it's certainly true, as a practical matter, that most AppleScript programmers, sooner or later, do become concerned about speed. You've developed a script, and it's working, but when it runs it's taking longer than you think it should. You want to know whether there's anything you can do to make your script faster. A few general considerations will put speed into perspective:
Things are better than they used to be AppleScript is a lot faster than it once was, not just because we're all using vastly quicker computers these days, but because the runtime engine has been made more efficient. AppleScript used to be downright sluggish, and this was very noticeable back in the old days when computers had floppy disk slots and less than 4MB of RAM (and we all had to clean the streets with our tongues on the way to school). That's no longer the case.
Interapplication communication is a bottleneck AppleScript is all about communicating with other applications. It (AppleScript) isn't supposed to be fast, because it isn't supposed to be doing much of anything. It's supposed to be sending Apple events to scriptable applications, and as soon as it does that, speed is completely out of its hands; having handed an Apple event to the system to dispatch, AppleScript can do nothing but waitand that's what most of a script's execution time probably consists of, waiting for some target application to receive an Apple event, do what it says to do, and return a reply.
Only repetition really matters Considerations of speed are probably not worth raising at all unless your script performs some sort of repetition, meaning either a handler calling itself recursively or a repeat blockand even then, not until the number of repetitions becomes significant. It is here, in a repetition, that a small difference in speed one way or the other can accumulate, as the same code is performed again and again, so as to have a big impact on how long your script takes to run.
|
