AppleScript_ The Definitive Guide - Matt Neuburg [205]
set total to total + (item i of my L)
end repeat
total -- 12502500, and it took less than a second
The magic word in that code is my. Take it away, and the code takes 22 seconds to run; with it, the code runs in less than a second. (Discovery of this remarkable device is generally credited to Serge Belleudy-d'Espinose.)
Now suppose all of that code is part of a handler, where L is a local variable. You can't take a reference to L, so you'd have to use the trick of making L a script property. To do so, you might have to create a script object expressly for this purpose; that may seem silly, but it's worth it:
on myHandler( )
set L to {}
script myScript
property refL : L
end script
set total to 0
set bignum to 5000
repeat with i from 1 to bignum
set end of L to i
end repeat
repeat with i from 1 to bignum
set total to total + (item i of myScript's refL)
end repeat
return total
end myHandler
myHandler( ) -- 12502500, and it took less than a second
I've been unable to arrive at a rule explaining what causes list access to be slow and when it isn't. In the examples in this section, the first repeat block (containing set end of) is fast; it's the second repeat block that's slow. But this does not mean that set end of is always fast. Sometimes it's slow too, and I don't know why. However, all you need to know is that, in such cases, the tricks with reference-based or property-based access will speed it up. So these should be among the first weapons in your arsenal when you're looking for ways to optimize your code.
Scripting Additions
One of the main reasons for using scripting additions is speed. For repeated trigonometric calculations, for example, it is certainly going to be a lot faster to use a scripting addition, such as the Satimage osax, than to roll your own calculation (as disingenuously suggested at Apple's web site). Similarly, a scripting addition that implements transformations to a list, such as returning a list with a particular element deleted, is going to be faster than coding the same operation in AppleScript (see "LISP-likeness" in Chapter 4). Just how quickly a scripting addition is called, however, depends on how you call it.
The osax architecture is such that a scripting addition appears to be present "inside" whatever application is being targeted when the scripting addition command is called. This behavior is noticeable, and useful, when a scripting addition puts up some user interface. For example, if the display dialog command is called from within a tell block targeting the Finder, the dialog appears within the Finder; it's as if you'd given the Finder a new dialog.
Behind the scenes, though, this architecture involves a serious inefficiency. The application itself is sent the Apple event denoting a scripting addition command. Obviously the application can't deal with this Apple event, so at that point the message is sent on up to the realm of scripting additions as a kind of fallback. This means that when you use a scripting addition command while targeting an application, that command must be routed through an extra step. This takes time, and in a context of repetition, the time adds up significantly.
If, on the other hand, you use a scripting addition command outside of any tell block, or within a "tell me" block, the message is sent directly to the scripting addition, which is faster by about an order of magnitude—a very significant difference. Here's a script that demonstrates.
set t to the ticks
repeat 5000 times
tell application "Finder" to get offset of "i" in "ticks"
end repeat
set t1 to (the ticks) - t
set t to the ticks
repeat 5000 times
tell me to get offset of "i" in "ticks"
end repeat
set t2 to (the ticks) - t
return {t1, t2} -- {944, 71}
Context
The context or environment from which a script is executed can make a huge difference to its speed. This is in large measure because Apple events are expensive. In particular, what makes them expensive is the context switch involved in communicating between one application