I assume everyone has noticed the speed difference between an AppleScript Studio App and a plain AppleScript. My guess is that it has to do with the Objective-C bridge. Is this correct or is it something else?
Thanks,
-r
I think speed differences are connected to some kind of UI/System issue/hooks when you run the code. For example, I experiment the same speeds running the same code in Smile or in a Studio-app’s “on clicked” attached to a button (against, for example, attached to a “run” handler in a regular applet, or to “awake from nib” in a Studio-app, which is much slower).
Not something related to obj-c (I think), but the way and circumstances the code is run on.
Thanks jj,
Since I introduced AppleScript Studio to the guys at work they were curious as to what the cause of the speed difference was. I told them I thought it had to do with the Objective-C bridge but I’d post the question to find out for sure. Thanks for that clarification.
Much appreciated.
-r
I think the scripts in the xcode app are already translated to a format that is easier to read for the mac. Just got the idea: Try to save a normal script in the script editor as run-only. I think that is were this translation happens.
But I’m not sure about this.
The compiled script should contain the same code when compiled from various sources (Xcode, Script Editor, osascript, Smile, Script Debugger, “store script”, etc.), as it must be finally read and run by the AppleScript component.
The things which is variable is the “run mode”. For example, the differences on speed execution of Apple’s Script Editor against Smile I think are joined to the various tasks the editors will do before running the script. For example, when you click “run” in SE, it will first deactivate the run button, activate the stop button, and installs some kind of listener so you can stop the running script (which implies a blinking cursor in the front window, etc.). Smile, on the other hand, is already-ready to run the script. You hit “run”, and that’s all. The app freezes while the script is running, so it’s using all its power to execute the code. SE’s behaviour is creating some “extra noise” in the system and, as such, slowing a bit the speed.
This is pure speculation, but for sure the same source code matches the same executable code (or, otherwise, it couldn’t be interpreted by the AS component). This means that the code isn’t compiled by the script editor (Xcode, Smile or whatever), but by a unique routine in the OS (I think this one is bundled in the AS component).