Skip to content

AppleScript Profiling

An Script Debugger feature that I’ve been pondering for a long time is a profiler. Given that Script Debugger’s debugger has the ability to track each statement executed, I can capture quite a bit of data about time spent in handlers, and even particular statements. I can also track AppleEvents back to the statement that initiated them.

A little bit of this information is presented in the existing Script Debugger interface. Firstly, the script timer (bottom of result drawer) displays the number of AppleEvents sent and breaks execution time down into time spent executing in AppleScript and time spent waiting for AppleEvents. The AppleEvent Log window’s contextual menu lets you go to the source statement that generated a particular AppleEvent.

My experience is that most AppleScript performance issues can be traced to inefficient sending of AppleEvents to other applications. As a result, my curiosity is in the tracking of events sent to other applications. But my usage patterns tend to avoid implementing anything but the most trivial algorithms in AppleScript due to its poor string handling and list performance. I also tend to avoid the use of script objects because of they are quite buggy in my experience.

Given all this, what are the questions you need an AppleScript Profiler to answer? Feel free to add a comment to this post or email me directly with your thoughts.

3 Comments

  1. I actually do lots of string and list manipulation with my SmartString script object and don’t find it buggy at all, and the speed of development is more important than the speed of execution.

    In that vein, I think your assessment that you should profile AppleEvents instead of pure AppleScript is correct, however, I think you’ll be surprised by the amount of pure AppleScript code being run out there.

    As for script objects, I don’t doubt that there’s a raft of issues with complex script objects, but they have their uses and seem to work for what I’ve used them for, which is largely function/data encapsulation.

  2. Daniel Lord Daniel Lord

    I rarely use any Applescript more than a page or so long–the lack of robust functions that come so easily in Python as well as anything but a poor rudimentary UI capability has me going to Python and wxPython consistently now. I even write my Xcode User Scripts in Python and wxPython. When I need Apple Event support I use the appscript module for Python which nearly always does the job for me. In short, Apple Event profiling would be useful but Applescript profiling would not interest me at all. It is a shame apple doesn’t provide an off-the-shelf high-level Apple Event module for the built in Python. Perl, and Ruby. PyObjC isn’t even close: it is too low-level and always has quirky corner cases and missing coverage in the bridge that drives me either all the way to C++/ObjC or to script with Python/wx/appscript.

  3. Adam Bell Adam Bell

    Jon Pugh said: “In that vein, I think your assessment that you should profile AppleEvents instead of pure AppleScript is correct, however, I think you’ll be surprised by the amount of pure AppleScript code being run out there” and I concur, but having said that, I would say that many of my AppleScripts are “pure vanilla”, so I would like both features. Like Jon, I haven’t had trouble with script objects which I often embed in scripts to improve large list handling e.g., sorting mostly.

Comments are closed.