From: hengist podd Date: 2009-04-30T03:31:19+09:00 Subject: Re: Trouble with OSA and Excel Robert Schaaf wrote: > Hengist, > > 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 too. 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 it's designed. > 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. HTH has -- Posted via http://www.ruby-forum.com/.