インデックス・サイズで約8倍の差
インデックスの作成時間は，テキストの抽出処理と単語の切り出し，そしてインデックスを生成する一連の処理量で決まる＊3。処理量が多いほどCPUの処理時間を長く使い，メモリーを消費して仮想メモリーの読み書きによる性能低下が起こる。先に計測した平均CPU使用率と仮想メモリーに対する読み書きの回数が，作成時間を左右するはずである。
500Mバイトの測定対象ファイル群のインデックス作成時間を見てみると，ConceptSearchとGoogleデスクトップ検索，サーチクロス，そしてSpotlightの4製品が5分前後で並んだ（図5[拡大表示]）。圧倒的に高速なのが，QuickSolutionパーソナル体験版。約2分でインデックス作成が終了した。CPU使用率が低く仮想メモリーに対する読み書きが少ないことが功を奏したようだ。
しかしインデックス作成直後の体感速度は，6製品中最も遅かった。マウスカーソルを動かそうとすると，ひっかかるような重さを感じた。プログラムがなるべく物理メモリーを利用する構造になっていると思われる。
生成したインデックスのサイズは，製品によってまちまちだった（図6[拡大表示]）。500Mバイトずつ容量を増やした際に分かるのは，インデックスの圧縮率や情報の多寡である。一般にインデックスは圧縮して格納する。圧縮率が高いほどインデックスは小さくなる。
情報の多寡は，関連度の算出に使うデータの数や，プレビュー機能に使うテキストデータを保持するかどうかで変わってくる。また，Googleデスクトップ検索やMSNサーチツールバーwith Windowsデスクトップサーチのように，Exifを含む画像ファイルやID3タグを含むmp3ファイルをインデックス化する場合は，インデックスの項目そのものが増えるため容量が多めになる。
特徴が表れているのは，QuickSolutionパーソナル体験版とSpotlight。前者は関連度を算出するために，ファイル内の単語の数や位置を記録する。さらにn-gram方式を採用するため，インデックスの項目数が多くなる。500Mバイトの測定対象ファイル群に対して，インデックス・サイズは約63Mバイトだった。後者のSpotlightは，インデックス・サイズが約8Mバイトにとどまった。形態素解析による単語の切り出しをしていること，検索結果のソートに使う関連度を算出しないことなどの理由から，インデックスが保持するファイル関連のデータが少ないようだ。
