Lightningフローのレコードトリガの性能

SalesforceのSpring20からLightningフローにレコードトリガ更新ができるようになりました。
レコードの保存前後で起動できるLightningフローになります。
簡単に言うと、コーディングをしないApexトリガですね。

Spring20のLightningフローに関するリリースノートを見てみるとこのような記述がありました。

フロー内の保存前更新は、プロセスビルダーで作成されたレコード変更プロセスでの更新よりも 10 倍高速です。

おおっ、プロセスビルダーの10倍とはなかなかの好スペック！
そこで、実際の更新速度がいかほどか検証してみました。

検証方法

項目更新について、以下の方法で4つの方法で実施し、それぞれの処理速度を調べます。

オブジェクトは以下のカスタムオブジェクトを使用します。
名前と日時項目だけのシンプルな項目で、レコードを作成時に日時項目にシステム時刻を自動セットするようそれぞれ①〜④の方法で作成します。

①ワークフロールール＋項目自動更新による更新

作成時に無条件で実行日時を更新する処理を実施。

②プロセスビルダーによる項目更新

プロセスビルダーでも同じように、実行日時を更新するプロセスを作成します。

③Lightningフローによる項目更新

以下レコード変更フローを作成し、割り当て処理で実行日時を更新します。
このように定義することで、beforeトリガと同じように項目反映前に値を書き換えることが可能になります。

④Apexトリガによる更新

以下のBefore、Insertトリガで実行日時を書き換えする処理を入れます。

trigger HogeInsertTrigger on Hoge__c (before insert) {
    List<Hoge__c> hogeList = Trigger.new;
    for(Hoge__c hoge : hogeList){
        hoge.datetime__c = Datetime.now();
    }
}

①〜④はやり方が違うだけで、やっている処理は全て同じです。

測定方法

それぞれの方法に対し、開発コンソールのOpen Execute Anonymous Windowから1000レコード分まとめてInsertして、その処理時間を測定します。

List<Hoge__c> insertList = new List<Hoge__c>();
for(Integer i = 0; i < 1000; i++){
    insertList.add(new Hoge__c(Name = String.valueOf(i)));
}
// 開始時間
Datetime startTime = Datetime.now();
insert insertList;
// 終了時間時間
Datetime endTime = Datetime.now();
// Insertにかかった時間（ミリ秒）を測定
System.debug(endTime.getTime() - startTime.getTime());
delete insertList;

検証はレコードを空にした状態で行い、実施のたびにレコードは削除します。
処理時間は開発コンソールのInsert前後で日時をとり、その差分から処理時間を算出します。
データ仕込みの時間や削除の時間は考慮しません。

①〜④それぞれを3回ずつ実施して平均をとります。
検証するもの以外は無効化にしておきます（①を有効化した場合は②〜④を無効化といった感じ）。

検証結果

①〜④それぞれに対しInsertにかかる時間を測定したところ、結果は以下のようになりました。

このように、Lightningフローを使った項目自動更新が一番速いことがわかりました。
プロセスに比べ、10倍とまでは言いませんが、それでも4倍以上もスピードが上がっています！
今回は単純な代入処理だけでの検証ですが、フローが複雑化するともっと数字に開きが出るかもしれません。

今後はLightningフローが主流となる!?

以上の結果から、性能面でもLightningフローが優れており、使わない理由がなくなりました。

今後は削除に対するフローも実装されるとのことなので、よりLightningフローが発展していくことが予想されるため、フローを触ったことがない方も是非活用できるようにしておきましょう。