Benchmarking in 'do shell script'

I like to show my conclusion of benchmarking AppleScript. When we do compare of some
algorithm or method to use we should also consider what application we use to execute it.

With this simple example to run 100 do shell script. (maybe that was not what you think)

Ps. I have only include 5 different way to execute code. I use seconds and with round to nearest
decimal. If its more closer to half I use that instead. I have also measure some execution with
my mobile and round to the nearest decimal - 0.5 sec

Lets assume you have always thought do shell script is slow. To run 100 do shell script
in a applet or osascript in less 2 seconds I do not think is slow. I have done similar test
with python print function and that was less 1 second.

Why Apple Script Editor take more 1 minute and 30 seconds to execute is very strange.

Benchmark of ‘do shell script’ Running Script

Script to execute:

set x to 0
repeat with i from 1 to 100
	set x to x & (do shell script "echo " & i)
end repeat
display dialog (last item of x) as text

So would it be far to compare AppleScript with AppleScriptObjC and JavaScript
when we do not talk how we execute it and only the method or algorithm it use.

Only my conclusions and believe… there is some serious bugs or something else that infect the overall speed in Apple’s Script Editor.

To do more research I run this code in Apple’s Script Editor and its only took 2 sec to complete.
So running 100 do shell script from Script Editor with AppleScriptObjC to execute Automator workflow with input is faster and any Script Editor include Script Debugger (tests above).

To execute below code in Script Debugger give the same time as Apple’s Script Editor.

So could we make the conclusion that run script in Automator is faster and it was
to Run AppleScript action. I’m not sure… if applet and osascript in command-line
was the fastest in this example code I could understand run script was faster and run AppleScript.

use AppleScript version "2.5" -- macOS 10.11 or later
use framework "Foundation"
use framework "Automator"
use scripting additions

property theResult : missing value
property theError : missing value

set theScript to "
	set x to 0
	repeat with i from 1 to 100
		set x to x & (do shell script \"echo \" & i)
	end repeat
	display dialog (last item of x) as text

on runWorkflow:theObject
	set {theURL, theInput} to theObject as list
	set {my theResult, my theError} to current application's AMWorkflow's runWorkflowAtURL:(theURL) withInput:theInput |error|:(reference)
end runWorkflow:

set theInput to theScript

set thePath to "/Users/f.gustafsson.user/Desktop/runAS.workflow"
set theURL to current application's NSURL's fileURLWithPath:thePath
my performSelectorOnMainThread:"runWorkflow:" withObject:{theURL, theInput} waitUntilDone:true
if theError is not missing value then error theError's localizedDescription() as text
return theResult as list


Lets pipe text (action) to run script in Automator and compare to Run AppleScript action…
that was slower but not much. The time to get text and pipe the text string to next action
we lose some speed. The strange part is… that is exactly what we do in Script Editor when
we pipe text string input with AppleScriptObjC but its much faster to display the dialog box.

Lets compare vanilla AppleScript (first script) with pipe workflow AppleScriptObjC (second script)
with Script Geek and every time I run it the vanilla AppleScript was slower.

– do shell script 100 times
Vanilla AppleScript 2,2 sec
AppleScriptObjC 1.8 sec.


Lets save the (first script) to doShellScript.scpt and load it as script object and run script.
And compare it with the AppleScriptObjC workflow script. Now you will see to load a script object
and execute it with run script is slower and runnings a vanilla applescript (first script).

set thePath to load script (path to desktop as text) & "doShellScript.scpt:" as alias
run script thePath

To run it from separate script and execute it is slower (Apple’s Script Editor).

If Apple’s Script Editor and Automator is the only option for you. And you think your code is slow
I would consider to run it as applet or osascript. I would also consider to use Automator with
AppleScriptObjC. All this depends what your algorithm/functions does.

Its very clear to me:
Apple’s Script Editor is the slowest option (in my test) compare to other options to execute AppleScript code. That doesn’t mean its everytime… it could happen and you maybe are thinking its something wrong with your code and that is not the case.

It could be when we measure things we also use other application to execute it for measure.
Same code in different application do different things to reach the result.

So how could we do this in a broken Apple’s Script Editor.
Maybe like this.

do shell script “open ~/”
do shell script “osascript ~/my_script_with_100_doShellScript.scpt”

The execution of 100 do shell script in the repeat loop use applet or osascript and become
much faster to return the result we want in Script Editor. If we know do shell script is slow
and we know applet and osascript is faster why not use that instead.

Now Apple’s Script Editor only take 2 second to execute 100 do shell script.

Or more correct in Script Geek… 0,9 sec to execute.
do shell script “osascript ~/Desktop/doShellScript.scpt” – do shell script in repeat loop (100 times)


Lets compare osascript vs script editor.
As you could see osascript use C++ Standard Library and do not use any security framework.
You also see it doesn’t use OSAKit and if we do the same with applet you will only
find CoreServices framework.

Would it be correct to assume that C++ Standard Library and lacking of security framework
would be much faster and Script Editors implementations to execute source code.

If anyone know more I would be very happy for any respond ??

Editors like Script Editor and Script Debugger provide logging. To do that, they use callbacks with AppleScript – as a script sends Apple events, AppleScript in turn effectively calls code within the editors. This instrumentation unavoidably adds overhead.

There can also be other factors slowing things down: editors generally run scripts on background threads, so they can do the stuff of showing you what’s happening on the main thread. Script Debugger’s own timer attempts to allow for overhead in calculations, but there are limitations.

The point is that editors are designed for editing — speed of execution isn’t relevant to them. Would you want inferior logging so a script runs faster as you’re writing it?

Your second sentence is the crux of the matter. I’m afraid much of your speculation is wide of the mark.

Shane, logging is important in many situation and very userful. If application A is almost 20 times slower and application B that do the same things (Editor, logging…)
I would think its something wrong… (what its I do not have any clue)

Why I wrote this topic was:
To compare algorithms and methods I’m of believe we need to remove the noice before
we could do any compare in speed what so ever that include logging.

I provide example showing the slowest on my machine 90sec to fastest 1sec and the code
was the same. I didn’t change the code I only execute it differently.

And many benchmark on this forum have been about algorithm and methods and that is not
what this topic is about. I wrote it because I learn many things I didn’t know before.

If logging is interfering greatly and make pore speed I would think its serious problem.

I’d be curious to know what Mac and version of the OS. On my 2014 iMac running Catalina, your sample code in Script Editor takes, at a guess, about one second – maybe two if the log panel is open and displaying results.

(I’m a bit confused about your test code. Having a display dialog in there seems to me to make it inherently inaccurate – it’s timing human response. Maybe you used different code to what you posted.)


Do not laugh :slight_smile:
I will admit I have more 50 Script Editor document open… and it take 1.4GB memory.
Do think that is the reason?? :slight_smile:

I use Macbook Pro from mid 2012 with 16GB memory.

I don’t know if it’s the reason, but it doesn’t sound like an ideal benchmarking environment.

The exemplified echo to a standard addition is something that should never be done in practice, as it’s simply unnecessary, and I would characterize calling the shell 100 times in quick succession for any reason as a misuse that requires rethinking the methodology.

Shane, I promise I will return with a more accurate test… thanks for your inputs.

I will see if I could login in to my admin account I believe I have more resources and less noice.
Will let you know…

Have you check my ASOBjC code on Code Exchange ??