AppleScript much faster on Monterey?

I wonder if it’s just me - or AppleScript is much faster on Monterey?

In fact it’s just blazingly fast.

For example, I have a script that polls InDesign document’s elements for certain attributes.

On Monterey, it takes 15 seconds to scan this 96-page document.

On previous systems it was much longer: 85 seconds on Big Sur. So Monterey is about 6 times faster.

I witness similar speed improvements in other scripts.

1 Like

The issue has been blogged about a bit here (in Japanese) by @Piyomaru :

http://piyocast.com/as/

I believe the speed-up with AppleScriptObjC code is even greater.

We owe @Piyomaru a deal of thanks for pursuing the issue with Apple so tenaciously.

5 Likes

I can also confirm that AppleScript execution has improved significantly. UI scripting is also significantly faster.

However, especially with the latter, there are still a lot of bugs. One example:

-- Sample for ControlCenter scripting 
tell theMenuBarIterm
	click
end tell
set theCount to count of entire contents of window 1
--> 0
set theCount to count of entire contents of window 1
--> 14

This is not a time problem. One can wait infinitely via delay. The first query for the count (or other objects) will always answer with „0". Without the Script Debugger I would never have thought of it!

A word about the Shortcuts app:

If this is really going to be the replacement for Automator, then good night. It feels more like a toy app.
However, you can execute AppleScript in it and also call shortcuts from AppleScript. Both with parameter passing. This is especially useful if you want to address apps that are otherwise not scriptable or want to use functions that are not available in the dictionary (e.g. calculate duration of a route, set url for reminders, etc.).

But: Even here there are still a lot of bugs. This already starts with the call of the shortcut. According to the dictionary, it should read as follows:

set theResult to run shortcut named "Test" with input theInput

After compiling it becomes:

set theResult to run shortcut named "Test" accepts input theInput

If you change anything in the script, the next compilation will fail. You have to replace accepts with with before.

And there are a few things to consider when passing parameters. So far I have only managed to pass the simple AppleScript types (string, bool, number, list). But even with these, within shortcuts you should cast them to the original type. For example:

on run {input, parameters}
	set theImput to imput as list
end run

Edit: Records not working (Thanks @Piyomaru).

Otherwise, problems will occur e.g. when using AppleScriptObjC.

In general, when using parameters, I recommend using the “Run AppleScript” action as the input action and the parameter return worked for me with the “Stop and Output” action.

Otherwise, the Shortcuts app seems to be a useful addition when you would otherwise not get anywhere. But nothing more - at least at the moment.

1 Like

That’s great to know, I send my thank to @Piyomaru as well.

I also should learn how to pursue issues with Apple tenaciously. Because my pursuit of issues with Apple is often fruitless.

P.S. Otherwise, Monterey is quite problematic on my machine. It takes forever to boot: 25+ minutes. Plus it already stalled and restarted by itself twice in one day. Some lengthy troubleshooting is ahead.

Try to turn off kernel extensions
It helped me

I too confirm a faster AppleScript execution, but not so drastic

Thanks I’ll look into this.

But at this point I know that other users experience exactly the same issue. So it’s a common problem with Monterey. We probably have to wait until Apple fixes it anyway.

I wish I could test all that, maybe in a Monterey update, right now it won’t install on non Apple SSDs… :frowning:

Well I’m not sure if there are some kind of exceptions, but you definitely can install Monterey on non-Apple SSDs. My system is on an external Samsung SSD, and some other users I discussed this issue with also run their systems from non-Apple external SSDs.

In any case, you probably don’t want to install Monterey just yet anyway. Because if you’re among those who’re affected by the super-slow startup issue you don’t want to learn about it the hard way!

For what I understand about AppleScript, Automator and Shortcuts, AppleScript is not going away any time soon.

Automator on the other hand is a problem, as those actions are Python 2 scripts and Python will probably not make it to next years release of macOS.

So AppleScript is built in, and Apple will improve on Shortcuts and get developer support increased for it, so over time Shortcuts will probably be better than AppleScript, but that is not now.

To be exact, macOS 11+M1 Macs runs AppleScript veeeeeeery slow.

M1 Mac + macOS 11 runs 10 times slower than 2012 MacBook Pro Retina.
I bought M1 Mac mini and found it slower than 2012 MBP soon.
Especially, AppleScript’s cocoa function calling was very slow. Cocoa Scripting sorting routine was slower than vanilla script sorting. I lost my words…

So, I reported it to Apple with detailed benchmarks. And they fixed.

Machine 1(M1) is macOS 11 environment. It was slower than 2011 MacBook Air + macOS 10.13.

Machine 1’(M1) is macOS 12 environment. It runs faster than other machines I have.

Machine 2(Core i5) is Mac mini 2014+macOS 11. It runs fast with macOS 12.

benchmark1_graph1-1

This is the performance demo movie of my full written in AppleScript app “Kamenoko” available on Mac App Store.

–M1 Mac mini + macOS 11

–M1 Mac mini + macOS 12

–Kamenoko performance demo with Intel Mac (left) and M1 Mac (right) on macOS 12

My “Uni Detector” application binary checker app is full written in AppleScript works fast with macOS 12. It isn’t nice?

Uni Detector’s most highest ranking is #28.

2 Likes

I have a nightly script that exports all of my contacts to individual .vcf files.

It took 4 to 4.5 minutes to run on Big Sur.

It takes under 90 seconds on Monterey

2 Likes