【ITニュース解説】How to benchmark a large CSV viewer or editor fairly

大きなCSVファイルを扱うビューアやエディタの性能を評価する際に、ただ時間を計測するだけでは公平な比較はできない。ツールごとに異なる「仕事」をしている可能性があるため、ベンチマークの前提条件を明確に定義し、何を測るのかを厳密に決める必要がある。この記事は、公平で信頼できるベンチマークを行うための具体的な指針と方法を説明する。

まず、ベンチマークの「ゴール」、つまり何をもってタスクが完了したとみなすかを明確に定義することが重要である。例えば、「最初の利用可能なビュー」とは、ファイルのオープンリクエストから、合意された数のレコードが画面に描画され、コントロールが操作可能になるまでの時間と定義する。「完全なスキャン」であれば、新規アプリケーションセッションのオープンリクエストから、全てのCSVレコードが解析され、正確なレコード数が返されるまでの時間とする。「フィルタリング」については、「未オープンソースからのフィルタリング」と「オープン後のフィルタリング」を区別し、それぞれ開始と終了の条件を定義する。さらに、編集したコピーを保存するタスクも、保存リクエストから出力が正常にクローズされるまでと明確にする。これらのタスクごとに、エンドツーエンドの時間を記録し、必要であれば内部的な処理フェーズも計測する。バックエンドがデータを返す時間と、ユーザーが画面上で結果を確認・操作できるまでの時間は異なるため、これらを混同しないよう注意が必要だ。

次に、ベンチマークの「正確性」を予測可能にすることが求められる。これは、既知の答えを持つ合成ファイルを使用して、ベンチマーク対象のツールが正しく動作していることを確認するステップである。CSVデータは単純に見えても、カンマ、引用符、埋め込み改行などの特殊文字が含まれると解析が複雑になることがある。物理的な行数とCSVレコード数は必ずしも一致しないため、これらの要素を考慮したテストファイルを用意することが重要だ。記事ではPythonスクリプトの例を示しているが、これは意図的に複雑なCSV形式（カンマ、引用符、埋め込み改行など）を含むモックデータを作成し、特定のルール（例えばレコードIDが97で割り切れるもの）に合致するレコードがいくつあるかという既知の答えを提供する。このスクリプトは、レコードをメモリに全て読み込むのではなく、逐次的に処理することで、大きなファイルでも効率的に動作する。データの生成、フィルタリングと書き込み、そして検証の各ステップを個別のタイマーで計測することで、それぞれの処理にかかる時間を明確にする。ただし、このフィルタリングのタイマーには出力の書き込み時間も含まれるため、インメモリでのクエリ時間とは直接比較できない点に留意する必要がある。

さらに、ファイルの「オープンコスト」と「クエリコスト」を可視化して測定することも重要である。これは、「新鮮なセッション」（アプリケーションを起動し、ソースファイルを開いてからクエリを実行し、結果を表示するまでの全プロセス）と、「既にオープンされている状態」（ファイルが既に開かれており、クエリを送信してから結果を表示するまでの時間）の二つのワークフローを分けて計測することを意味する。どちらの場合も、使用するカラム、比較のセマンティクス（例えばテキスト検索と厳密な一致）、一致するレコード数、リクエストするページサイズなど、クエリの条件を統一する必要がある。また、結果の正確性を確認するために、最初のページだけでなく、中間のページや最後のページも検査し、ソースレコードIDと一致するレコード数を検証することが欠かせない。

「編集機能」のテストも独立して行うべきである。これは、合成データファイルのコピーを用意し、特定の修正（例：レコードID 97のステータスを「review」から「checked」に変更）を一つだけ加えるシナリオを考える。その後、修正後のデータを別の出力ファイルに保存し、その出力ファイルを独立したCSVリーダーで再度開き、修正が正しく反映されているか、元のレコード数が変わっていないか、そしてカンマや引用符、埋め込み改行などが正しく処理されているかを確認する。元のソースファイルが変更されていないことも確認する必要がある。保存時間と、再オープンおよび検証にかかる時間は個別に報告し、もしユーザーが直面するタスクにこれら両方が含まれる場合は、合計時間も報告する。ソート機能のテストにおいても、数値IDは数値として比較し、出力された全てのレコードが一度だけ現れていることを検証し、重複するソートキーに対してはタイブレーカー（順位決定の追加ルール）を定義することが重要である。最初の数行だけを見てソートが正しいと判断することはできないため、完全な検証が求められる。

ベンチマークでは、「リソース使用量」を測定することも不可欠である。これには、アプリケーションプロセスツリー全体のピークメモリ使用量、一時ディレクトリの増加（解凍されたファイルやインデックスを含む）、一時的な作業スペースとは別の出力コピーのサイズなどが含まれる。フィルタリングやソート後に、既定のページに移動するのにかかる時間や、キャンセル処理のレイテンシ、そして不完全な出力が明確に区別できるかどうかも記録するべきである。迅速に結果を返しても、バックグラウンドで大きな処理が実行され続けているツールは、他のツールと同じタスクを完了したとは言えない場合があるため、全体的なリソースの振る舞いを把握することが重要である。

最後に、「明確なキャッシュポリシー」のもとでベンチマークを繰り返し実行し、その結果を公開する必要がある。最低でも3回のマッチングした実行を行い、個別の値と中央値を記録する。この際、使用したオペレーティングシステム、アプリケーションのバージョン、CPU、RAM、ストレージの種類と場所など、実行環境の詳細も併せて記録することが不可欠である。アプリケーションを再起動しただけでは、オペレーティングシステムのファイルキャッシュが「コールド」（何もキャッシュされていない状態）になっているとは限らないため、実際にどのようなキャッシュポリシーを適用したかを記述することが重要である。再利用可能なインデックスなどの恩恵を受ける場合、以前の実行が後の実行にどう影響したかを明確にするため、過去の実行結果も可視化しておくべきである。役立つ結果シートには、ツール/バージョン、ソースバイト数、レコード数、キャッシュ/インデックスの状態、タスク、準備時間、実行時間、利用可能な結果までの合計時間、ピークプロセスツリーメモリ、一時ファイルのピーク、出力バイト数、正確性チェックの結果、キャンセル時の挙動、および特記事項といった項目を設けると良い。有料機能が利用できない場合は「ライセンスなし」と明記し、ツールが応答しなくなった場合は、そのアクション、観察間隔、リソースの挙動を詳細に記述し、完了時間を推測してはならない。これらの厳密な手順を踏むことで、自分のデータに対してどのワークフローが最も時間を節約できるのかを、再現可能で信頼できる結果に基づいて特定することが可能となる。