AppleScriptの実行速低下は観測されていませんが、日本語環境でNSDataDetectorでテキストから電話番号を抽出できないバグは治っていません。

2021/10/19にApple Eventがオンライン開催されることが発表され、どうやらMacBook Pro 16インチにApple Silicon搭載モデルが出てきそうだ、と見られています。果たしてどうなりますやら。

Cocoa Scripting Course本のVol.4「System Hardware & Software Information」の執筆のために基礎調査を行なっていた段階で気づいていたのですが、macOS 10.15あたりからFrameworkの再編が行われていて、AというFrameworkの下位Frameworkとして存在していたBというFrameworkが、macOS 12あたりで独立したりと位置付けがいろいろ変わっています。

具体例を出すと、みんな大好きPDF操作用のPDFKit。これまでPDFKitはQuartzCoreフレームワークの下位フレームワーク（Umbrella Framework）として存在していました。それが独立したため、AppleScriptでも、

use framework "QuartzCore"

などと書いていたものを、

use framework "PDFKit"

などと書き換える必要が出てきました。

なかなかこのあたりの問題が顕在化しないのは、実行環境側でPDFKitをincludeしていると、AppleScriptもそのご利益にあやかってuse frameworkが目的のものを指していなくても、実行できてしまっているためです。

ところが、別のランタイム環境（Script Menuとか）に持って行くと、そちらではPDFKitをincludeしていなかったりする場合に、「PDFDocumentなんて知らないよ？　allocできないよ？」という話になってしまいます。とくに、Script Menuはエラーの出力先もない「寡黙な実行環境」なので、エラー発生源がよく分からないんですね。

そして、Script Menuから呼び出すScriptにいろいろエラートラップを仕掛けて発生しているエラーを調査し、この問題が発生していることが判明したわけです。

もしかしたら、AppleScript ver. 2.8でバージョン番号をあらためる必要があったのは、内部的な要因（Apple Silicon Macへの最適化）もさることながら、こうしたOS内のさまざまな変更が大きいため、それを区切る必要があると判断されたためなのかもしれません。

macOS 10.13以降、ながらくAppleScript Version 2.7の時代が続いておりました。

正直なところ、macOS 10.15でScripting Additionsを廃止したあたりとかでバージョン番号を変えておかないとまずくないか？　と思っておりました。サードパーティのScripting Additionを使えなくした、というのは世界観の大きな分岐点といってよいでしょう。

AppleScriptの処理系そのものには手を加えていませんよ、互換性に問題が出たりはしませんよ、というメッセージをこめて意固地にバージョン番号を変えてこなかったのかと思っていました。

それが、macOS 12beta9でAppleScriptのバージョンを「system info」コマンドで確認していたところ（Cocoa Scripting Course続刊作成のため）、2.8という数字が表示されていることに気づきました。

{AppleScript version:"2.8", AppleScript Studio version:"1.5.3", system version:"12.0", short user name:"me", long user name:"XXXXXXXXXX", user ID:504, user locale:"ja_JP", home directory:alias "Macintosh HD:Users:me:", boot volume:"Macintosh HD:", computer name:"M1 mini", host name:"m1mini.local", IPv4 address:"192.168.0.xx", primary Ethernet address:"99:99:99:99:xx:99", CPU type:"ARM64E", CPU speed:missing value, physical memory:16384}

上記の実行例はM1 Mac miniの実行結果ですが、Intel Mac上でも同様のAppleScript Version 2.8という結果を返します。

Apple Silicon Macの「真の能力（ちから）」を発揮するバージョンとしての2.8なのか、それともiOSを含めたショートカット的な世界観を含んだ2.8なのか、テーマ設定がどこにあるのかはわかりませんが、ここで１つの区切りをつけたいんだろうなという「意図」は感じます。

AppleScript Version 2.7の期間のmacOSときたら、史上最低最悪の事故物件であるmacOS 10.13、大失敗を容易に２度繰り返してしまったmacOS 10.15、トラブルが絶えずβ版という印象がぬぐえなかったmacOS 11など、macOS 10.14以外は（それ自体も末期になるまで使う気がしなかった）あまり思いだしたくないOSバージョンばかりで、これらとの訣別という意味において「2.8」の数字を冠する（臭いものにはフタをしたい）という意図であれば一定の理解は可能です。

バージョン2.8になったからといって、64bit化されたCocoa Finderに対するフィルタ参照の実行速度が上がったりはしていません。Finderによるファイル操作は、「現在選択中のファイルの取得」「最前面にオープンされているWindowのターゲット取得」ぐらいにとどめておいたほうがいい（遅いので）という傾向が変わることはありません（Cocoa系の機能を呼び出すと100〜1,000倍ぐらい高速）。

これら以外に、何か意味が込められているのかはインサイダーではないため不明ですが、とにかくVersion 2.8というバージョン番号が振られたことについては認識しておく必要があることでしょう。

macOS 10.13の大失敗が、キリスト教国における不吉な数字としての「13」に起因するものであるとしたら、macOS 12の次の「macOS 13」は不吉な存在の集合体であり総決算でもあるわけで、ぜひとも開発プロジェクトの瓦解の真相究明と公表が求められるところです。

macOS 12 beta7からほどなく、beta8が出てきました。どうやら、このbetaか次あたりでリリースしたい様子が伺われます（推測）。

レポートずみのバグは修正されていませんが（確認された事実）、Release版で駆け込み修正が行われるか、Release後に後付け修正するつもりなのでしょう（希望的観測）。

macOS 10.13のときにRelease版が壊滅した（客観的事実）のは駆け込み修正の整合性がとれていなかったためと見る（推測、憶測）筋もあり、それに懲りて「GM」宣言をやめました（客観的事実）し、駆け込み修正を行わないように方針を転換したように見えます（観測結果からの意見）。

現状のmacOS 12beta8のままリリースされれば、自分が見ている範囲ではそれほど悪くない出来でしょう（個人の感想）。

→ Beta8でIntel Macで外部ディスプレイに表示できないというバグが発生したもよう。Intel Mac miniで動作確認していますが、こうした構成ではなくノートなど本体にディスプレイを搭載しているモデルの話でしょうか

Shane StanleyのFrameworkバイナリ入りAppleScript Library「Bridge Plus」「Myriad Tables Lib」「SQLite Lib2」がApple Silicon対応していました。

それぞれ単独の配布アーカイブではApple Silicon対応していないのですが、「Shane’s Script Library Pack」でまとめて配布されているものはApple Silicon対応のUniversal Binaryでビルドされています。

インストーラーはAppleScriptアプレットになっており、実行すると……これらのライブラリがインストールされていません。このため、Shane Stanley本人に聞いてみたところ、これらのインストール対象のライブラリがすでにインストールされている場合には、あらかじめ削除しておいてほしいとのこと。

……それはわかりませんでした（＾ー＾；；

m1mini:~ me$ file /Users/me/Library/Script\ Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus 
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/Users/me/Library/Script Libraries/BridgePlus.scptd/Contents/Frameworks/BridgePlus.framework/Versions/A/BridgePlus (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

あれ？　Dialog Toolkit PlusもFramework同梱ライブラリですが、これに含まれていないような、、、、
→ ああ、バンドル内にFrameworksフォルダが存在しているものの、中身はありませんでした（Thanks Shane!）

M1 Mac miniで各種ベンチマークをとってみたところ、「どうやらAppleScriptを高性能コア（Firestorm）ではなく高効率・省電力コア（Icestorm）」で実行しているのでは？　と、疑っていました。

10倍遅いというとショッキングな数値に見えますが、問題はこれが「まだマシな方」の結果であり、トータルで77倍遅い処理があったりと、目を疑いたくなるような結果のオンパレードです。

そんな中、アクティビティモニタの「ウィンドウ」＞「CPUの履歴」で各CPUコアの履歴とともに種別が表示されることが判明。

冗談抜きで、AppleScriptがIcestormで実行されているのではないか、という状態になっています。

M1 Mac＋macOS 11上で各種ベンチマークをとってみたところ、Intel Mac＋macOS 10.14よりも大幅にパフォーマンスが低下する例が頻発。NSMutableArrayに21万項目の項目を追加するベンチマーク（５回計測して平均値を計算）を走らせてみたところ、

　MacBook Pro Retina 2012（Intel Core i7 2.6GHz、macOS 10.14.6）：8.69秒
　Mac mini M1 2020（M1 3.2GHz、macOS 11.5beta）：104.25秒

M1 MacがIntel Mac（しかも2012年のマシン）の77倍も処理時間がかかるという結果が出ています。このため、AppleScriptをFirestormではなくIcestormで動かしているのではないか、という疑問が出ていました。

とくに、M1ではAppleScriptのrandom number（乱数計算）コマンドが極端に遅く、これを使ってテスト用に乱数データを作ると腰が抜けるほど時間がかかります。シーケンシャル値の続く配列を作ってGamePlaykit.frameworkを用いてシャッフルするのがよさそうです。ただ、本当にM1でrandom numberの計算をさせると遅くなります。

700箇所の位置情報をもとに、日本全国の最寄りの鉄道駅を計算する距離計算を行なったところ、M1 Mac miniでは2012年製のMacBook Pro Retina 2012の10倍処理時間がかかりました。

GUIアプリケーションにちょこちょこ命令するだけとかいう、「単なるマクロ言語」としての世界観（小乗AppleScript）で使う分にはよいのですが、アプリケーションに依存せず単体でデータ処理を行なったり、Mac App Storeで販売するGUIアプリケーションまで記述して実行しているわけで、Icestormで実行してほしくはありません。

Intel Macで６分あまりの処理にM1 Macでは60分以上かかっています。2012年のマシンに比べて2021年製の最新鋭のマシンがまさに文字通り「桁違いの遅さ」を見せているのが現状です。

実行中のアクティビティモニタの表示を見ると、高性能コア（Firestorm）への負荷はあまりかかっておらず、逆に高効率コア（Icestorm）への負荷が集中していることが見て取れます。

Intel Mac上で実行中には、4コア8スレッドのIntel Core i7の各コア（4コア）に均等に負荷がかかっていることが見て取れました。

M1 Mac miniの基本性能の高さはグラフィック性能やディスクI/O性能を中心に実証されているため、あくまでOS側の「味付け」の問題が原因と見ています。

AppleScriptが単なる「GUIアプリケーションをちょこっと自動化するだけのお可愛らしいマクロ言語」なのであれば、Icestormで実行するという話も悪くはないでしょう。ただ、Mac App Storeで販売しているGUIアプリケーションから各種データ処理を行うシビアな処理を行う処理系でもあり、やはり2012年のIntelマシンの10倍とか77倍遅いという現状は面白くはありません。

を注文しました。WWDC21でハードウェア系の発表が行われなかったということは、少なくとも2021年中に現行のM1 Mac以上のマシンを投入できないものと判断したためです。

さすがにMacBook Pro Retina 2012では物理的にも性能的にも無理があり、メインマシンとして入れ替えることになります。まだ「上海を出た」ぐらいの距離感です。

RAM 16GB、SSD 1TB構成です。RAM 8GB構成だと割と整備済製品や店頭販売品があるのですが、さすがに8GBはないだろうと。RAM 8GB構成だとSSDのSwapが激しいとのことなので避けてみましたが……実際に動かしてみないとなんとも言えません。

SSD 256GBでは「悪い冗談」、SSD 512GBだと「いまと同じ」、SSD 1TBぐらいが実用上の最低ラインだと判断しました。ポート数が少ないので、ディスプレイ以外で接続しておく周辺機器は最低限のものにとどめておくべきマシンでしょう。

YouTubeをはじめとして各種ベンチマークが掲載されていますが、正直なところムービー書き出しとかゲームやベンチマーク専用ソフトの結果ばかりで、実際に一般的なアプリケーションを動かして、アプリケーションをAppleScriptから操作してゴリゴリにコキ使ったときのパフォーマンスはどこにも載っていません。

Script Debuggerで巨大なScriptを編集すると、文字入力が止まるぐらい遅くなるので、Script Debuggerの操作が軽くなることを期待したいです。

以前に開発用にiMac Proを一時的に預かっていたときにすこしだけ自作ベンチマークをとってみましたが、あれよりも突っ込んだ内容は実験できることでしょう。iMac Proはいいマシンでしたが、（MBPR 2012よりも）３〜４倍ぐらい高価なiMac Proでも1.5倍ぐらいのシングルコア性能で、コストパフォーマンス的にはいまひとつでした。つまり、高い割にたいしたことがない、という印象。

M1 Mac miniにはとても期待しています。

M1 Macでベンチマークをとってみたい処理

・巨大な配列を使う処理
与えられた文字列の1D Listのすべての順列組み合わせパターン文字列を返す v3
→ これは、M1 Mac上でとくに遅い処理で、心底ガッカリしました。この挙動は問題ありすぎなので、Appleに報告して対処してもらえるよう「お願い」をしています

２点間の距離を求める v3
→ 全国のゲームセンターの最寄りの鉄道の駅を求める
→ 2012年のMacBook Proのほうが10倍速いです
・画像処理
画像の空白判定 v4
→ これは、2012年のMacBook Proより高速でした

画面スナップショット超解像バッチ処理 v1
→ M1内蔵のニューラルエンジンを利用しているためか、これはM1 Macが圧倒的に高速です
２つの画像が類似しているかを判定

ghostscriptによるPDFの圧縮・軽量化処理
→ MBP 2012で数分から10分ぐらいかかっていた処理が、１分ぐらいで終わるので速いと思います。ただし、瞬時に終わるとかいうことはありません

・アプリケーションとのやりとりが膨大で重い処理
Mail.appでメールボックスの仕分けを行う（最重量）
→ これは、Intel Macとさほど変わりません。ただ、Mail.appの起動がアホみたいに速い（起動してから操作可能になるまでのタイムラグがほとんどない）ので、その点だけでもM1のトータルなシステムとしての速さを実感できます
CotEditorのウィンドウを楕円運動
→ M1のほうが少し速いか？　ぐらいで、全般的にこの手のScriptはMBP2012の10倍遅いことを覚悟する必要があります
・AppleScriptで組んだGUIアプリケーションの動作
Kamenoko
→ ±ゼロぐらい。しばらく動かしていると動作が止まる瞬間があって、強制終了させたりしています
・重いアプリケーションの動作
巨大なScriptをScript Debuggerでオープンして編集したときの動作
→ Intel Macに比べて速い、ということは感じません。この用途でいえばiMac Proの方が快適かも？