[変数を設定] のかわりに [計算式を挿入]
Twitter で、今泉さんが、大沢ちゃんとの会話で…（意訳）「くそほどループするときとか、[変数を設定] のかわりに [計算式を挿入] の方が速いのよね！」とか言ってたので、探求モードへ。
ググってみたよ
ヘルプでその辺言及してるのは見つけられなかったけど、丁度ソコに言及している投稿は見つけられた
Use "Insert Calculated Result" to concatenate strings! <= Groundbreaking Performance Leap!
要点かいつまむと…
- [変数を設定]スクリプトステップは [immutable variable] をセットします
- かたや、$varをターゲットとした[計算結果を挿入]スクリプトステップは、[mutable variable] をセットします
- だから、Loopなどで $var が複数回書き換えられる場合、[計算結果を挿入]（insert calculated result だから ICRと略すらしい）は、（特定のケースにおいては）よりパフォーマンスに優れてるらしい
- テストしなきゃなケース
- 既に存在する変数のテキストを上書きする
- 変わらず
- 変数の末尾になんらかのテキストを付加する
- えらく変わる
- JSONSetElement を使ってテキストブロックのセットされた変数にテキストを挿入する
- JSON関数を使うか使わないかに関わらず、デカいテキストブロックであればあるほど変わる
- 変数を一度だけ宣言する
- 変わらない
たしかに、[変数を設定]だとメモリ空間を無駄遣いするという意味では [ICM] の勝ちだけれど、末尾に追加する場合じゃないとそんなに変わらないと言ってる人とか、色々居てカオス。つか、選択オプション使ったらあんま変わんないじゃんとか…。
計算式の設定に行きたいのに、スクリプトステップをダブルクリックしても、SV だと要らんダイアログ通るのがイヤ。ICMだとダブルクリックで計算式ダイアログが出てくれるのに…とか言い出す人。ｗ
（これはClaris FileMaker Community にログイン要るのかも）
Use "Insert Calculated Result" to concatenate strings! <= Groundbreaking Performance Leap! を書いた人が、ランダムにレコード複製して、JSONにレコード内容をスクレイピングしていくというスクリプトでテストしてた
[変数を設定] 25分/100,000レコード
[計算結果を挿入] 1分半/100,000レコード
変数を設定 vs テキストを挿入
- これも 変数をターゲットにして [テキストを挿入] で変数をハンドルできる
- でも、[テキストを挿入] だから、変数に使う場合でもテキストしか入らない
- 何と言っても、（HTMLとか）そのテキストがダブルクォーテーション使ってる場合とかだと、エスケープとか要らなくてラク
- [計算結果を挿入] と同じく、末尾にappendとかだと、アホほど速い
結論
- 変数を（Loopとかで）何度も上書きするなら…
- 名前空間的な意味で言えば、 [変数を設定] に比べて[計算結果を挿入] がいくらか以上は有利
- どんどん末尾にappendしていくとかだと[変数を設定] に比べて[計算結果を挿入] がアホほど速い
- 姉妹品の [テキストを挿入] もよろしく！
追記（2021/05/21）
山本センセ@Facebook 曰く…
さらに単純に＄rに固定の文字列を上書きするだけの処理を繰り返しても、シンプルに10万回繰り返すよりも改善がみられた。そこで仮説。「変数を設定」の処理は、変数を新たに追加し、同じ変数名を探して利用できないようにするのに対して、「計算式を挿入」は変数名をさがすだけで、結果を変更している挙動の様である。文字列の追加の場合は特に効率がよい。ならば、そもそも「変数を設定」はいらないじゃないか。ということになる。「計算式を挿入」は変数の定義がなければ自動的に変数の定義もしてくれる。変数に限れば「計算式を挿入」は「変数を設定」のスーパーセットであり、フィールド設定と計算式を挿入の関係のような、フォームに存在するしないに影響されることもない。それでは「変数の設定」の存在意義はなにか。互換性のために残っているに過ぎないのか。