Making applescript run faster...

Camelot wrote:
When it comes to performance tuning, though, the same rules apply in AppleScript as in any other language - it requires profiling to identify which areas are slow and therefore where to concentrate your resources.

Ditto that. It's pointless trying to optimise until you know where the bottlenecks are. In your script? In the application? In the cross-process communication?

It's also worth remembering that AppleScript is a global, system-wide language and, as such, it has to be all things to all applications. Contrast this with VBA which is highly optimized for specific applications and you can see why a similar VBA script might be faster, but with some tuning you should be able to get close.

I'd disagree with this statement for a couple of reasons:

1. The AppleScript language itself is dog slow compared to most any other general purpose scripting language you care to mention. (To give an idea: these days I do all my non-trivial automation scripts using Python+appscript. Python's hardly renowned as a speed demon itself, but I still reckon it's at least 10x faster for the non-application stuff.) That said, this is only a factor if your script is doing a large amount of data munging itself; if all it does is control other processes then AS's own slowness is unlikely to be the main bottleneck.

2. VBA and AppleScript communicate with Excel via very different APIs that likely have very different performance characteristics. (That's a polite way of saying that Excel's Apple event API is almost certainly significantly slower than its VBA API.) Both ultimately operate on Excel's low-level Automation API, I'm going to guess that the VBA API is a more natural fit and thus has lower overheads. Apple events are kinda weird and applications usually have to do a fair bit of work to map them to their internals.

There may be other factors as well, but those two are the ones to look at first.

Hello Jason,

Some tips.

• When processing (large) list, define the list as property and use reference to that property in referencing to list's item. This will yield remarkable performance improvement (60 - 80 times faster as far as I can tell).

E.g. 1 Given -

--CODE1 (blooming slow)
set xx to {}
repeat with i from 1 to 1000
set end of xx to i
end repeat
set yy to {}
repeat with i from 1 to 1000
set end of yy to (xx's item i) * -1
end repeat
return yy
--END OF CODE1

--CODE1A (fast)
property xx : {}
property yy : {}

repeat with i from 1 to 1000
set end of my xx to i -- # note the usage of "my"
end repeat
repeat with i from 1 to 1000
set end of my yy to (my xx's item i) * -1 -- # idem.
end repeat
return my yy's contents
--END OF CODE1A

--CODE1B (fast and well-behaved)
main()
on main()
script o
property xx : {}
property yy : {}

repeat with i from 1 to 1000
set end of my xx to i -- # note the usage of "my" (or "o's")
end repeat
repeat with i from 1 to 1000
set end of my yy to (my xx's item i) * -1 -- # idem.
end repeat
return my yy's contents -- # return its contents, not reference
end script
tell o to run
end main
--END OF CODE1B

CODE1A and CODE1B are much faster than CODE1.
CODE1A will preserve the property values beyond each run while CODE1B won't.
In case you're employing 'reference to list defined as property' technique for performance' sake, CODE1B should be better because it won't leave unwanted dirty data behind.

*Note that you should return the contents of the reference not the reference itself, if need be, especially when you're using this technique in one of your handler which is called many times.
E.g., if you return "my yy" in lieu of "my yy's contents" and use "set aa to main()" in lieu of "main()" in CODE1B, the dynamically instantiated script object (o) cannot be released even after the handler exits because there remains an object (aa) which is bound to it in the outer script. If you return "my yy's contents", the script object (o) can be released peacefully.



• Reduce the number of costly inter-application communications.

E.g. 2 Given -

--CODE2 (pseudo-code)
set xx to {}
repeat with i from 1 to 100
set end of xx to value of cell i
end
--END OF CODE2

--CODE2A (pseudo-code)
set xx to value of cells 1 thru 100
--END OF CODE2A

CODE2A (if it's possible) should be faster than CODE2.
(CODE2A sends 1 event while CODE2 sends 100 events to Numbers.)

E.g. 3 Given -

--CODE3 (pseudo-code)
repeat with i from 1 to 100
set value of cell i to (value of cell i) * -1
end repeat
--END OF CODE3

--CODE3A (pseudo-code)
property xx : {}
set xx to value of cells 1 thru 100
repeat with i from 1 to 100
set value of cell i to (my xx's item i) * -1
end repeat
--END OF CODE3A

CODE3A (if it's possible) should be faster than CODE3.
(CODE3A sends 101 events while CODE3 sends 200 events to Numbers.)



• If Numbers has its own script menu, call the script from there. In most cases, script run via application's own script menu runs (much) faster than script run as stand-alone applet. Perhaps AppleEvent addressing mode is different between them, I'd guess.

• Inter-application comunication in applet is slower than that in Script Editor. There's a way to improve applet's performance by using 'run script' command in applet.
Something like the following template, which is designed to preserve any properties in your main code (whether or not it is terminated by error).

*Note that this template swallows any error thrown in your main code. So it's not good for developing and/or debugging your code.

--APPLET TEMPLATE
script o
script o1
-- # place your main code here
end script
try
tell o1 to run
on error --
end try
return me
end script

set o to run script o -- to preserve the properties in o1
--END OF APPLET TEMPLATE

cf.
A relevant topic: Applet speed
http://discussions.apple.com/thread.jspa?threadID=1633798&tstart=0



Hope this may be of some help,
H

Message was edited by: Hiroto (fixed typo)

Hi all of you

glad to meet Camelot, jason and Hiroto in the same thread.

We have a lot of things to discover in Numbers.

For Hiroto's information : Numbers has no specific script menu.

It obey the modern rule:

to reach the dedicated scripts from a menu, store them this way:
<startupVolume>:Users:<userAccount>:Library:Scripts:Applications:Numbers:transpo se4numbers.app:

Here you see ":" at the end of the path because I saves this kind of script as Application Bundle.

CAUTION, even Mac Os Hints may post a wrong script (I comment one of them in http://discussions.apple.com/thread.jspa?messageID=8770643)

For jason's information : Matt Neuburg's The Definitive Guide is a good source of infos.

For Camelot's information : If you know a way to tell GUIscripting which table of which sheet must be duplicated, I am interested 😉

Yvan KOENIG (from FRANCE dimanche 25 janvier 2009 17:43:42)

A lot of things from System 7 no longer apply, but some of them do, especially when dealing with loops and lists (arrays).

When it comes to performance tuning, though, the same rules apply in AppleScript as in any other language - it requires profiling to identify which areas are slow and therefore where to concentrate your resources.

It's also worth remembering that AppleScript is a global, system-wide language and, as such, it has to be all things to all applications. Contrast this with VBA which is highly optimized for specific applications and you can see why a similar VBA script might be faster, but with some tuning you should be able to get close.

I'd disagree with this statement for a couple of reasons:

Au contraire. You appear to agree with me.

... I'm going to guess that the VBA API is a more natural fit and thus has lower overheads. Apple events are kinda weird and applications usually have to do a fair bit of work to map them to their internals.

This is the same thing I said, just using different words.

VBA for Excel, was written specifically for Excel., based around features that Excel has, and without any overhead for things that Excel does not support.
AppleScript, on the other hand, can do anything, anywhere and therefore is much more general-purpose. Consequently it doesn't have the focussed hooks and syntax that VBA does.

I think we're both saying the same thing here. 🙂