AppleScript Much Faster in 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 really noticed this with OmniFocus. I use this script to defer a selection of actions until tomorrow. It used to take what felt like almost 1 second per action. I could see them changing color one-by-one. Now it processes 20 actions almost instantaneously.
The issue has been blogged about a bit here (in Japanese) by @Piyomaru.
I believe the speed-up with AppleScriptObjC code is even greater.
Takaaki Naganoya (Apple translation):
At least Cocoa call speed, which was extremely slow in macOS 10.15, has been improved (even on Intel Mac), and Cocoa call speed on Apple Silicon Mac has been greatly improved. It’s 30-40 times faster than macOS 11. This is because Cocoa function calls from AppleScript were extremely slow on macOS 11+Apple Silicon Mac (not the high-performance core “FireStorm”, but the high-efficiency core “IceSt” This is because the point that was executed in “orm” has been corrected.
Even if you don’t use Cocoa’s features, it’s faster than macOS 11, so I recommend updating to macOS 12 for Scripter using M1 Mac (workplace apps Except if there is a policy not to update to maintain compatibility with theケーション).
It is also affected by structural changes in the OS. As previously reported, the framework in macOS is reorganized around macOS 11 (the one that was Umbrella Framework is independent. In particular, it is necessary to rewrite it to point to another thing with the use command.
8 Comments RSS · Twitter
Fascinating. I wonder if this was preparation work for the Shortcuts app?
I think it was largely fixing bugs. AppleScriptObjC used to be much faster, but something happened around macOS 10.14 and its speed dropped by close to an order of magnitude. Even with that, it was still fast enough (relatively) that people just lived with it, and put it down to security changes or somesuch.
[…] berichtet hat der Entwickler Michael Tsai hier. Seinen Informationen aus der Community zufolge sind AppleScripts in macOS Monterey bis zu sechsmal […]
[…] that may be welcome, such as an improved interface in the Finder when copying large files and AppleScript being reportedly much faster in Monterey. Plus, as Howard Oakley notes, Apple seems to be focusing its bug fix and security attention on […]
Archiving 17k emails from Outlook which is done primarily with AppleScript:
iMac from 2018 High Sierra, not even an SSD: 22min
Newest MacBook Air from 2021, Monterey latest beta: 45min
What does this tell me?
I got some advice with macOS 10.15.x-11.x AppleScript Cocoa scripting slowdown matter from Shane.
So, I reported this to Apple with various speed measuring results and test scripts.
I reported "Your company's newest M1 machine seems over 10 times slower than MacBook Air 2011."
I found macOS 11 execute AppleScript with M1's weaker core "IceStom". So, my AppleScript based apps are slowdown in macOS 11.
https://www.youtube.com/watch?v=-IcA9FWt1GI
Now, all speed down issue seems to be fixed.
I think Shortcuts.app is completely useless. It is worse than Automator.
I am having considerable problems with a third party AppleScript that will compile BUT am unable to save the compiled script as it always reverts to uncompiled in the save operation. Even the originator of the Script does not know what is going on. This is Monterey 12.5.1.
There also seems to be another problem that has just cropped up while trying to run the script 'freestanding' instead of from the application's Extensions menu. What I do it bring up the uncompiled script in AppleScript, compile it then run the script resulting in an error message in one of the subroutines, "System Events got an error: Script Editor is not allowed to send keystrokes."
Does anyone know what is going on?
Sparkgapper
I frequently need to grab thousands of tracks and their info from a Music app library using ITLibrary framework. Seems to me it would take a few seconds per thousand. Now, I can index a 40K track library in about 3 seconds.
Zooma zooma zoo-ma zoom!