rex0220 計算式プラグインにおいて、パフォーマンス改善の2大機能である 「計算フェーズの無効化」 と 「イベント処理の抑止」。これらを組み合わせることで、アプリの計算処理負荷を最小限に抑えることが可能です。
ただし、これらは 「計算処理に時間がかかり、業務に支障が出ている場合」 の最終手段に近い改善案です。安易な設定は予期せぬ計算漏れを招くため、メリットとリスクを正しく検討しましょう。
概要
「計算処理1」と「追加画面表示」・「編集画面表示」イベント計算の抑止で、パフォーマンス改善を行います。
計算式プラグインの各種設定で、下記を無効にします。
・「計算処理1」
・「追加画面表示」「編集画面表示」
- 各種設定
- レコード複写画面： 項目の値変更とレコード保存時に再計算
1. 組み合わせによる改善の仕組み
交通費申請アプリを例に、以下の2つの設定を同時に行った場合の動作を見てみます。
設定例：交通費申請(手段別合計)
- 計算フェーズ: STEP1（基本計算）を無効に設定
- イベント設定: 「追加画面表示」「編集画面表示」を抑止に設定
この設定での動作
- 画面表示時: プラグインは一切動きません。レコードは瞬時に表示されます。
- 編集時: テーブル内の値を変更した時だけ、**STEP2（集計）**が動き、合計金額が更新されます。
- 保存時: 保存ボタンを押した際にも計算が実行され、最新の状態で保存されます。
2. 改善効果の冷静な見極め
この組み合わせは、特に 「テーブル行数が多いレコードを頻繁に複写・編集する」 アプリで効果を発揮します。
-
改善のメリット:
画面を開くたびに走っていた「基本項目のスキャン」と「表示時の全計算」がカットされるため、体感的なレスポンスは大きく向上します。 -
過度な期待は禁物:
計算項目が数個〜数十個程度の標準的なアプリでは、これらの設定を行っても体感差はほとんどありません。 「1レコードに100行のテーブルがある」「計算式が数百箇所設定されている」 といった、明確なボトルネックがある場合のみ有効な手法です。
3. 設定に伴うリスクと設計上の注意
便利さと引き換えに、以下のリスクを設計者が管理する必要があります。
⚠️ 最新化のタイミングを失うリスク
画面表示イベントを抑止し、さらにSTEP1を無効にしているため、「画面を開いただけで値が最新に切り替わる」機能が完全に停止します。
- 前回の保存後にアプリ側の「単価」マスタが変わっていたとしても、編集画面を開いただけでは古い合計金額が表示されたままになります。
⚠️ 計算式の「追加忘れ」が命取りに
後から「STEP1」に該当する計算式（通常の数値計算など）を追加しても、フェーズが無効化されているため、いくら値を変更してもその項目は計算されません。
- 「設定したはずの式が動かない」という混乱を招きやすく、メンテナンスの難易度が上がります。
4. 判断基準：この組み合わせを導入すべきか？
| 検討項目 | 導入を推奨するケース | 導入を控えるべきケース |
|---|---|---|
| 現状の速度 | 画面表示や値変更に数秒の待ちがある | 特に不満なく動いている |
| データの鮮度 | 保存された値が正しければ、表示時の再計算は不要 | 常に「現在時刻」や「マスタ値」を反映させたい |
| 管理体制 | 設定内容（抑止状況）をドキュメント化している | 誰でも自由に計算式を追加・変更する運用 |
まとめ：パフォーマンスと保守性のトレードオフ
- 「現状で問題がなければ変えない」が鉄則。
- 重い場合に限り、ボトルネック（表示イベントなのか、スキャンフェーズなのか）を特定して個別に抑止する。
- 両方を組み合わせる場合は、将来の改修時に「動かないフェーズがあること」を忘れないよう、必ず記録を残す。
パフォーマンスの改善は、常に「正確な計算結果の担保」が最優先であることを忘れないようにしましょう。