ripgrepは巨大単一ファイルでも最速なのか — 51GB・8.9億行で rg / grep / UwView Pro を実測した

rgが、grepに負けた。

51GBのログを渡されて rg を叩く——リポジトリ検索と同じ手つきで巨大ファイルに向かった経験は、誰にでもあると思います。「検索は rg 一択」と言われるくらいですから。ではその一択は、巨大な単一ファイルでも成り立つのでしょうか。

測ってみると、意外な順位になりました。

測定条件
結果
なぜこうなるのか
正直に書いておくこと
使い分けの整理
使っている道具
リンク

測定条件

対象: OpenStreetMap 日本全域 japan-latest.osm（51.25GB・892,239,125行の単一XMLファイル）
検索語: 東京（ヒット多数の実戦的な語）
環境: Mac ＋外付けUSBストレージ（物理帯域実測 0.41GB/s）＝ I/O律速の環境
各ツールは次のとおり実行しました

rg 東京 japan-latest.osm > tokyo-rg.txt      # ripgrep
grep 東京 japan-latest.osm > tokyo.txt       # grep
# UwView Pro はGUIで同語を全文検索（初回=索引作成と同時／2回目=キャッシュ検索）

比較対象の UwView Pro は当方の自作ツールです。作者が測っている数字として、割り引いてお読みください。

結果

ツール	初回	2回目以降	備考
ripgrep (rg)	71.49 秒	毎回ほぼ同じ	毎回51GB全体を読む
grep	64.64 秒	毎回ほぼ同じ	単純ストリーム処理
UwView Pro	54.7 秒（索引作成と同時）	14 秒	初回に5.3GBの圧縮キャッシュを作成

この環境では、単一巨大ファイルの検索で rg は grep より遅いという結果でした。そして2回目以降は、キャッシュを持つ側が一桁近く速くなります。

なぜこうなるのか

rg の欠陥ではありません。設計の得意分野が違うだけです。

rg の並列化は「複数ファイルを同時に走査する」方向に効きます。ファイル1個では並列化の効きどころが乏しい
I/O律速（0.41GB/s）の環境では、どのツールも「51GBを読み切る時間」が下限になります。正規表現エンジンの巧拙より、ディスクが支配的です
grep が rg を上回ったのは、単純なストリーム処理のオーバーヘッドの少なさが、この条件では効いたためです

UwView Pro が初回からやや速いのは、読みながら行オフセット索引と圧縮サイドカーキャッシュ（5.3GB）を同時に作る設計のためで、本領は2回目以降です。毎回51GBを読むか、5.3GBのキャッシュを読むか——この設計の違いがそのまま差になります。

正直に書いておくこと

この結果はI/O律速環境（外付けUSB）での実測です。高速な内蔵SSDでは読み切り時間の下限が下がるため、順位や差は変わり得ます
rg の本領は多数ファイルの横断検索です。リポジトリ全体の検索で rg より速い汎用ツールを私は知りません
数値はすべて当方環境での自社実測で、独立ベンチマークではありません
UwView Pro の初回54.7秒も「ストレージの速度でファイルを一度読む」制約からは逃れていません。変わるのは、読みながら閲覧・検索できることと、2回目以降です