はじめに
速度を上げるばかりが、人生ではない。
マハトマ・ガンディー（宗教家、政治指導者）
ガンディーは義務教育で習うので説明は不要かと思いますが、関連するトピックとしてつい最近国連本部にガンディーの胸像ができました。
現代のビジネスパーソンは忙しいです。バースト的に到着するタスク、なぜか短縮される納期、突然来なくなったエンジニアの尻拭いなど、毎日の業務に忙殺されゆとりのない人生を送っている人も多いでしょう。OA化でオフィスへのコンピュータ普及が始まったのが1990年代。それから30年経ちテクノロジーも進化してもっと便利になったはずですが、不思議なことに私達の仕事にゆとりが生まれる気配は一向にありません。逆に昔と比べてゆとりが無くなったなんて声も聞きます。
仕事だけではありません。いまZ世代の間ではタイパ（タイムパフォーマンス）が重視されるようで、タイパ至上主義なんて言葉もあります。私はZ世代ではありませんがYouTubeとか倍速で視聴してたりするので、図らずもタイパを実践していたことになります。
そんな現代人にガンディーの言葉は我が身を省みるきっかけを与えてくれます。もっと社会全体がゆとりを持ち、できれば週休3日制を導入してほしいというのが私の願いです（勿論給料はそのままで）。
本題
ガンディーは速度を上げる必要はないと言っていますが、アプリに関しては基本的に高速であるべきです。ガンディーが現代に転生して「速度を上げるばかりが、アプリではない」などと宣ってもクライアントから怒られるだけです。もし相手が体育会系だったりしたらガンディーの非暴力に付け込んで拳が飛んでくるかもしれません。マイクロソフトもアプリのパフォーマンスについて以下のように言及しています。
アプリケーションのパフォーマンスを最適化する場合は、以下を行う必要があります。
- 使用されているデータ ソースと、取得するデータの複雑さを検討する。
- アプリケーションで使用されているデータ コネクタを評価する。
- 複雑で不必要なデータ ソースを削除しようとする。
- 特定のアクションに必要な特定の数のレコードのみを取得しようとする。
これを読んでデータソース毎にどの程度差が生まれるのだろうと思ったので検証してみました。比較するデータソースはPower Platformで利用されることが多いであろう以下のものです。
- Dataverse
- Azure SQL Database
- SharePointリスト
- OneDriveに置いたExcel
検証方法
Power Automateを使って各データソースにレコードを追加し掛かった時間を計測します。
Power Automateフロー
こんな感じのフローを作ります。開始時にデータソースと追加するレコード数を指定し、Switchで各々の追加処理へ分岐するという流れです。
レコード追加処理はすべてのデータソース共通でこんな感じです。開始時に指定された回数だけループしてレコードを挿入します。
開始時の入力内容はこんな感じです。
テーブルとデータ
レコードの追加先となるテーブルはこんな感じです。図はAzure SQL Databaseの場合ですが、他のデータソースも似たような型で定義しておきます。
テーブルには以下のようなデータをフローから追加していきます。
実行時間の計測
フローの実行履歴で確認します。
結果
それぞれ3回ずつ実行して平均をとった結果がこちらです。
OneDriveに置いたExcelが飛び抜けて遅いです。他3つはAzure SQL Databaseが若干速いくらいで似たり寄ったりですね。
感想
検証前はOneDriveに置いたExcelが一番遅いだろうと予想しており、結果はその通りだったのですが数値は予想以上でした。DataverseとSharePointリストも同様に遅い部類だろうと思っていましたが、Azure SQL Databaseとあまり変わらない結果になったのは意外でした（Webから使うとあんなに遅いのに）。
以上、本記事が仕事と人生において何かしらの参考となれば幸いです。