目下、ノートからデスクトップまでデュアルCPUが常識化し、AppleScriptでもこうした環境の変化を活用する方向でプログラムの構成を考えるべき時期が来たといったところだろうか。
普通にAppleScript/AppleScript Studioでプログラムを組んだだけでは、処理速度は１つのCPUの処理性能に依存する。もし、ガラ空きのCPUコアが他に存在していたとしても、現状では活用すべき術がない。
そこで、他に遊んでいるCPUコアがあればそれを活用してみようと考えるものだ。
第一段階。どの程度の数のCPUをシステムが搭載しているかを計測。これはBSDレイヤーのコマンドを実行すれば簡単に調べることが可能だ。問題ない。
第二段階。複数プロセスに分割して処理を実行するためのノウハウを考えてみる。AppleScriptで行う処理は一括処理的な内容のものが多いため、手分けできると早く終わるものも多く存在することだろう。
たとえば、データベースからのHTML書き出しであれば、A-JとK-Zまで手分けして処理した方が効率的なはずだ。
メインのプログラムから、子プログラムを別プロセスで起動して、そいつに命令を与えるわけである。別プログラムになっていれば、それぞれ別のCPUコアで実行されることが期待できる。
……で、4つのCPUコアがあればとりあえずあてずっぽうで子プログラムを４つ生成したいところであるが、ここでひとつ問題がある。どーやって複数のプログラムの実体を生成するか、ということだ。
オブジェクト指向的なアプローチはこの場合には有効ではない。スクリプトオブジェクトを生成して、パラメータを渡して実行というのでは、メインプログラムの中の一部として実行されるだけで、別のプロセスにはならないからだ。
おそらく、親プログラムのパッケージの中に子プログラムのファイルを隠しておいて、子プログラムをファイルとして別の場所にコピーして起動。子プログラムにAppleEventでパラメータを渡してスタートさせ、子プログラムの処理が終了したらデータをファイルで受け取るといったところか。
子プログラムを起動したら、親プログラムは子プログラムからの返答を定期的に待つだけの動作モードに。そして、所定のタイムアウト時間を過ぎても子プログラムが結果を返してこなかったときには、子プログラムを強制終了させて別プログラムに実行させるなりなんなりする必要があるだろう。
…………大量のJPEG画像の破損チェックやらデータの変換などを行う分にはこうしたアプローチが有効であるに違いない。さらに、CPUの負荷率を計測しながら「もうちょっと突っ込んでも大丈夫そうだ」などと判断して、さらに多数のプロセスを起動してもよいだろう。
終了した子プログラムは、ファイルを削除して痕跡を消去。こう考えると、子プログラムの種（コピー元）はZipアーカイブでも行って親プログラムのパッケージの中に入れておくとよいのかもしれない。
ものすご〜く乱暴で即物的でレベルの低い処理になりそうだが、用途によっては有り余るCPUパワーを活用できてよいだろう。さらに、この仕組みを発展させるとネットワークごしに他のマシンにプロセスを送りつけて実行させるような使い方もできるわけで………………
そこまで考えて気がつく。「ああ、これってほとんどXgridの仕組みそのもの」………。
どうせなら、Xgridの仕組みをのっとってAppleScriptの処理を行ってもよいだろう。どうせシェルからAppleScriptの実行もできるわけで…………いろいろと調べておくとよいかもしれない。
