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:
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.
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 wait—and 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.
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 block—and 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.
In order to improve speed, you have to measure it. At the crudest level, you can do this with the current date command, which captures the date-time at the moment it is issued, but this is good only to the nearest second. A better choice is the command the ticks
from the Jon's Commands
osax; this is particularly good for timing things, since a tick is about one-sixtieth of a second. Examples will appear later in this chapter.
Script Debugger can also help you quantify speed. It doesn't yet provide true code profiling (reporting the time spent on different sections of your code), but it does report how long the script took to run and how much of that time was spent within AppleScript and how much was spent sending Apple events and how many Apple events were sent. It also provides code coverage, indicating what lines of your code were actually executed, so you don't waste effort optimizing areas of your script that aren't doing anything.