2025 年 8 月 24 日に投稿した記事『LotusScript でビューを検索するメソッドの違い』で「GetAllDocumentsByKey より GetAllEntriesByKey のほうがパフォーマンス面で有利」と説明しました（以降、”前回の記事”といいます）。
ところが後日、実際に検証を行うとまったく逆の結果が出ました。まさかと思いつつ、改めて HCL テクニカルサポートに問い合わせたところ、私の検証と同じ結論（前回の結果の撤回）が返ってきました。今回の記事では、前回の記事の訂正とともに、両メソッドの特性について最新の知見をまとめておきます。
前回記事の要旨
前回の記事では、両メソッドの特徴を次のようにまとめました
| GetAllDocumentsByKey | 文書そのものを一つ一つコレクションすることから比較的に遅い |
| GetAllEntriesByKey | ビュー索引を活用する仕様 索引は軽量であり、メモリ消費も少なく高速に動作 |
2025 年 8 月の Domino Lounge Osaka でこの話をしたところ、同じ理解をされている方が多数いたのでこれが ”定説” だったことがうかがえます。
検証したら...真逆!?
どれぐらいパフォーマンスに差があるのか気になり、簡易的に検証したところ、GetAllEntriesByKey の方が ”数倍遅い!?” という結果がでました。
測定した項目は次の 5 項目です。GetAllEntriesByKey では高速なはずの ColumnValues による値の取得だけでなく、文書オブジェクトを取得して、値を取得するテストも行いました。
| シナリオ | GetAllDocumentsByKey | GetAllEntriesByKey |
| コレクション作成 | GetAllDocumentsByKey で検索し、コレクションを取得 | GetAllEntriesByKey で検索し、コレクションを取得 |
| エントリ取得 | GetFirstDocument、GetNextDocument で文書を取得 | GetFirstEntry、GetNextEntry でエントリを取得 |
| 値の取得 | 文書から値を取得 | ColumnValues で値を取得 |
| 文書の取得 | － | Document プロパティで文書を取得 |
| 文書から値の取得 | － | 文書から値を取得 |
結果は次の通りで、GetAllDocumentsByKey の方がずいぶん早かったのです。
はじめは、私のテストケース設定が悪く特徴を捕まえ損ねたと考えましが、より明確にメソッドの特性を理解するチャンスとばかりに、検証に使用した NSF（データと検証のコード）をサポートに送付して質問しました。
冒頭に記載した通り、返答は驚きの結果でした。”定説” とは真逆で『GetAllDocumentsByKey の方が高速』とありました。かなり丁寧な検証を実施いただいたようで、複数のテストケースに対して目的、検証手順、結果、考察をまとめた詳細なレポートと検証に利用した NSF が添付されていました。
検証レポートの要点
レポートでは、両メソッドの挙動が処理フェーズごとに整理されていました。
| 処理フェーズ | GetAllDocumentsByKey | GetAllEntriesByKey |
| コレクション作成 | NotesDocumentCollection は内部構造がシンプルで軽量 | NotesViewEntryCollection は内部構造が複雑で初期作成コストが高い |
| エントリ取得 | GetNextDocument はコレクション内のポインタ移動だけで圧倒的に軽量 | GetNextEntry は移動のたびに複雑なオブジェクトを生成・破棄が発生 |
| 値の取得 | NotesDocument は読み込むフィールド数に比例してコスト増 | NotesViewEntry は列数が増えると内部的な配列生成など処理コストが増加 |
表を見てわかるように、すべてのフェーズで GetAllDocumentsByKey が優勢となっています。
”定説” 逆転の背景
HCL サポートの見解では、主に以下の２点の要因が指摘されていました。
| I/O コストの低下 | かつての HDD 環境では、文書データへのアクセスのようなランダムアクセスは大きな遅延要因であったが、現在の SSD 環境になり劇的に短縮。 |
| ボトルネックの変化 | I/O コスト低下により処理時間の主たる要因がディスクアクセスからオブジェクト操作などのプログラムの内部処理へ移行 （ストレージの I/O → CPUやメモリ） |
文書を開かずビュー索引を使用したほうが早いという ”定説” は、ストレージが HDD だった過去の環境から導き出されたものだったということです。
現在の環境においては、GetAllEntriesByKey の複雑な内部処理が圧倒的に重く、フィールド数が多いなど文書操作が重くなる状況でも逆転することはないとのことでした。
今どきの”定説”
HCL サポートからのレポートは私の簡易的な検証とも一致する結果でした。
現在の一般的な環境では『GetAllDocumentsByKey のほうがパフォーマンス面で有利』という結論です。
前回の記事の内容は、この知見を踏まえて、完全に撤回し訂正いたします。
ちなみに、GetAllEntriesByKey を使う利点は、次のような用途に限られます。
- ビューのソート順通りに取得したい
- ビューの列の値にアクセスしたい
検証は大事
今回のような訂正記事を書くハメになったのは、「メーカサポートの回答だから」と無条件に信じてしまったことが原因です。これは ”サポートを信頼できない” と言っているのではありません。自分で検証すると理解が深まり、結果的に応用の幅も広がるということを体験できてよかったと感じました。検証は技術者としてとても重要だと再確認できました。
今回の記事において、パフォーマンスを左右する要素としては
- ストレージの I/O
- CPUやメモリ
- 文書のサイズやフィールド数
- ビューの列数
があることを知りました。これらがどのように影響するのか、特性を知っておくとより理解が深まります。調査が難しいものありますが、可能な限り検証してまとめたいと思います。
お詫び
ノーツコンソーシアム主催の次世代エース養成ワークショップ（2025 年 7 月、10 月）では、訂正前の内容を紹介しておりました。当時の私にとっては ”新しい知見” だったので、少し得意げに紹介してしまったことを反省しております。
ここでお詫びしても受講者のみなさま全員に届くとは限りませんが、この場を借りてお詫びいたします。今後はより慎重に検証したた上で、研修テキストの作成をしてまいります。
0 件のコメント:
コメントを投稿