Women in Technology

Article:		Replacing AppleScript with Ruby
Subject:		Performance?
Date:		2007-02-27 10:16:58
From:		DaveLentz
So what's the performance like, compared to the same Applescript implemented as an AppleScript script, a compiled AppleScript app, and as implemented in Ruby with Apple Event support? Neither AppleScript nor Ruby are viewed as high-performance languages (admittedly, work is ongoing toward making Ruby faster). But the real reaason -- in the absence of performance concerns/constraints -- to select one scripting language over another is the ease with which it can be implemented and maintained. While I routinely mix AppleScript with other scripting languages via the osascript facility in the shell environment and the AppleScript "do shell script" construct, I find that the best thing about AppleScript is that when coming back to a complex bit of code written with a lot of time between now and then, the AppleScript is always the easiest to understand what is going on in the code. But I'm certainly not averse to extending the utility of Ruby in my scripting toolbox. Great Stuff,

Showing messages 1 through 2 of 2.

• Performance?
  2007-03-01 07:18:19  Matt Neuburg | [View]
  
  
  DaveLentz:
  
  You raise two unrelated issues.
  
  First, there's the question of actual timings. I haven't done formal tests, but rb-appscript sure feels a faster to me than running an AppleScript script. Of course most of the time in a real script is spent in communicating with and waiting for the target application, so the source language doesn't matter. But quite aside from the AppleScript compilation issue, AppleScript is full of hidden speed traps. Just the other day I wrote an AppleScript script that required accessing information in a List of 2000 Lists; the mere size of the list caused the script to bog down, plus the lookup involved looping through the whole LIst because AppleScript has no hashes. So basically my response would be that as soon as you need to get anything done other than talking back and forth with the target application, Ruby is faster and more liberating because you don't have to dance around and tweak in order to get decent performance.
  
  As for maintainability of complex code, I'm sorry, I don't agree at all. I can't maintain or even read an AppleScript script of any size. Ruby's object-orientation is all about maintainability, plus, as I say in my book, I find AppleScript's verbose English-likeness, and the bizarre verbal dances you have to do in order to perform simple string manipulation, completely illegible.

• Performance?
  2007-02-28 11:28:15  hhas [View]
  
  
  Performance varies a bit depending on what you're doing. For example, commands that move a lot of complex data between the application and Ruby tend to be a bit slower, since the conversions are largely done by Ruby code whereas AppleScript is pure C. My own feeling is you can probably expect appscript code to run maybe 30-90% as fast as the equivalent AppleScript code, which in real-world use seems to be "fast enough". Also, Ruby is far, far better at regular programming tasks than AppleScript is, so pretty much everything else needs less code and runs faster than it would in AppleScript, more than balancing things out.
  
  The other thing to bear in mind is that the most significant performance factor is usually the time it takes applications to evaluate queries and respond to commands - something that affects all users equally. While things have improved over the years, the focus of Apple event-based IPC has always been more on power than raw speed. The appscript manual includes some useful advice on eking out the best performance when carrying out more complex tasks.
  
  HTH
  
  has
  --
  http://appscript.sourceforge.net
  http://rb-appscript.rubyforge.org
  http://appscript.sourceforge.net/objc-appscript.html