Robert S. wrote:
Thanks for the reply. I have been using appscript for the better part
of a year, but thought to switch to RubyOSA with the idea that the
whole dictionary would be pre-cached, and thus faster than resolving
the terminology on invocation. But maybe appscript does some similar
caching? I never found it slow, but wanted to optimize AppleEvents,
which are high impedance to begin with.
Both appscript and RubyOSA parse an application dictionary the first
time you create an application object. Appscript is quicker at this as
it just constructs simple lookup tables whereas RubyOSA generates
classes, although as this is a one-off cost it’s only be a factor in
short-running scripts. Appscript caches the results over the process’s
lifetime, so creating additional application objects for the same
application is much faster; not sure about RubyOSA but it may well do so
RubyOSA might be fractionally faster than appscript at constructing
references (it’s ages since I’ve compared it so I can’t really
remember), partly as it doesn’t rely on #method_missing (which adds a
bit of overhead in appscript) and partly because it lacks a lot of the
functionality found in appscript so there’s somewhat less code involved.
I’m pretty sure any difference between different bridges’ performance
won’t be significant, however, as the biggest overhead in application
scripting is the time it takes for the target application to resolve any
object specifiers and perform the command. As a rule of thumb,
rb-appscript is typically 30-90% as fast as AppleScript, which is about
as fast at building and sending Apple events as you can get. (Commands
that return large numbers of references aren’t as fast as appscript
isn’t as fast at constructing those than AppleScript)
You might get slightly faster performance from appscript by dropping
down into the AEM APIs (which skip the #method_missing stuff and use raw
AE codes), or by using RubyCocoa/MacRuby with objc-appscript and static
glues (Jordan Breeding, who you can likely find over on macruby-discuss,
has been doing this). But I doubt it will make a significant difference.
The biggest improvement will come from reducing the number of
application commands you use in the first place, e.g. by having commands
work on more than one object at a time (there’s a chapter on
optimisation techniques in the appscript manual), though Excel’s
scripting interface provides little opportunity for this due to the way
BTW, where in the application bundle is the dictionary (formerly the
‘aete’ resource) hidden? I can’t find Excel’s.
AETE resources are held in .rsrc files. Use DeRez to extract them,
although I can’t think of any reason you’d want or need to.