FileMakerエンジニア
先月、7月9日にClaris FileMaker 2025がリリースされ早一月が経ちました。
Claris が AI 機能がさらに強化された最新リリース Claris FileMaker 2025 の提供を開始
AI機能の強化や、新機能の追加、パフォーマンスの改善などメジャーバージョンのアップグレードはいつも心が躍りますね。
Briller FileMaker Laboratory（BFL）にも取り上げられそうな題材があれば、またそちらも検証していきたいと思いますのでよろしくお願いします。
目次
テーマ
今回のテーマは「Loop処理のオプション毎の速度計測」です！
FileMaker（ファイルメーカー）2023（20.3.1）からLoopスクリプトステップにフラッシュのオプションが追加されたのはまだ記憶に新しいと思います。
しかし、このフラッシュを設定することでパフォーマンスにどのような影響を及ぼすのか、1年経った今でも説明を求められると詰まってしまいます。
よって今回、フラッシュのオプション毎に速度計測を行い、その違いを確認してみたいと思います。
Loopについて
開発者にとって繰り返し処理は慣れ親しんだものなので、Loopの概要は省かせていただきますが、上記のヘルプに記載されている通り、FileMaker（ファイルメーカー）のLoopスクリプトステップには以下のオプションが利用できます。
[常に]: データを変更するループ内のすべてのステップで、常にすべてのキャッシュされたリレーションシップをフラッシュしてすべての依存関係を更新します。これはデフォルトのオプションで関連データを正しく使用できます。
[最小]: データを変更するループ内のすべてのステップで、キャッシュされたリレーションシップをフラッシュして現在のテーブルオカレンスから 1 テーブル離れたリレーションシップの関連データとの依存関係を更新します。
[延期]: ループの開始時、現在キャッシュされているリレーションシップとデータを使用します。ループが終了するとキャッシュされたリレーションシップをフラッシュして依存関係を更新します。
これだけを見ても少々わかりづらいと思います。
下記のエンジニアリングブログにわかりやすい説明がされていますのでよろしければそちらもご覧ください。
Claris エンジニアリング ブログ：スクリプトのパフォーマンスを向上させるために [Loop] の [フラッシュ] オプションを変更するタイミング
環境とスペック
検証するにあたっての環境と実機のスペックを紹介します。
ソフトウェア：FileMaker Pro 21.1.1.41
OS：Windows 11 Pro（24H2）
CPU：12th Gen Intel(R) Core(TM) i5-12450H 2.00 GHz
メモリ：32.0 GB
検証方法
ファイルの準備
まずは下図のようなファイルを用意します。
フィールドは入力用のテキストフィールドのみとなっております。
新しく12,500レコードを作成するスクリプトを用意し、レコードを作成します。
スクリプトの内容
Loopスクリプトステップを用いて、フィールドへの入力を行い、時間を計測するスクリプトです。
スクリプト毎にLoopのオプションを変えております。
実行すると12,500レコードのテキストフィールドに、タイムスタンプを入力し、入力にかかった時間をミリ秒単位でダイアログに表示します。
速度測定
各計測毎に3回ほどスクリプトを実行し、平均した値（小数第四位を四捨五入）を結果として出します。
例：変数の計測で1回目が10.311秒、2回目が10.225秒、3回目が10.119秒で、平均10.218秒が結果となる。
検証結果
| 計測 | 1回目(s) | 2回目(s) | 3回目(s) | 結果(平均)(s) |
| 常に | 10.418 | 10.271 | 10.132 | 10.274 |
| 最小 | 10.086 | 10.257 | 10.129 | 10.157 |
| 延期 | 10.079 | 10.045 | 10.065 | 10.063 |
※レコードの全置換：0.286s
まとめ
検証の結果、計測毎の速度は以下のようになりました。
（早い）延期 > 最小 > 常に（遅い）
「Loopについて」にて挙げさせていただいたエンジニアリングブログでは下記のような記述がありました。
この説明がリレーションシップに関係なくLoopの処理速度としてなのかずっと気になっていましたが、今回の検証で確認する限り、大きな差ではないですが、処理速度として早くなっていました。
リレーションが参照されない可能性があるため、常に以外のオプションの利用は敬遠していましたが、リレーションシップと関係ない箇所や参照が必要ないときはフラッシュを延期にした方がいいかもしれませんね。
ただし今回のように単純な入力の場合、レコードの全置換を利用したほうがさらに早く処理できますので、状況に応じて使い分けるとよりパフォーマンスのよい開発ができると思います。
以上が【BFL vol.9】FileMakerのLoop処理をオプション毎に速度計測してみたの検証となります。
ここまで読んでくださって誠にありがとうございました。また次回のBFLもお楽しみに！
また、株式会社ブリエでは、FileMakerを活用したシステム開発や運用支援を行っています。
一括処理やパフォーマンスの改善のご相談もお気軽にお問い合わせください。
株式会社ブリエFileMakerエンジニア。ローコード開発を筆頭にプロコードからフロントエンドまで、多種多様な開発経験を活かしたフットワークの軽さが自慢のオールラウンダー。より便利に、より使いやすいUI/UXデザインをモットーに、新しい分野にも積極的に挑戦することで、あらゆるニーズに柔軟に対応できるよう、日々勉強を続けております。
