はじめに
先日、業務で急を要する調査があり、ログが送られてきました。いつもの調子で調べようと思ったら仰天。
容量が 40.69GB もあったのです。
当然VSCodeやテキストエディターは悲鳴をあげ、 grep を叩いたものの、一向に終わる気配がありません。
「これ、もっと速くならないのか?」と調べて出会ったのが ripgrep (rg) です。
あまりの爆速ぶりに感動したので、標準の grep との比較をまとめました。
検証環境
- OS: macOS [バージョン例: Sequoia 15.7]
- 対象ファイル: ログファイル(40.69GB / テキスト形式)
-
検索ワード:
"Exception"
比較:grep vs ripgrep
ベンチマークツール hyperfine を使って、各コマンドを10回試行した平均時間を算出しました。
1. 実行時間の比較
| コマンド | 平均実行時間 | 速度倍率 |
|---|---|---|
grep (BSD grep) |
130.095 s |
基準 |
ripgrep (rg) |
8.898 s |
約 14.62 倍速い |
2. ベンチマークの詳細
$ hyperfine 'grep "Exception" HUGE.log' 'rg "Exception" HUGE.log'
Benchmark 1: grep "Exception" HUGE.log
Time (mean ± σ): 130.095 s ± 1.356 s [User: 125.276 s, System: 3.967 s]
Range (min … max): 127.229 s … 132.437 s 10 runs
Benchmark 2: rg "Exception" HUGE.log
Time (mean ± σ): 8.898 s ± 0.129 s [User: 1.375 s, System: 3.175 s]
Range (min … max): 8.742 s … 9.137 s 10 runs
Summary
rg "Exception" HUGE.log ran
14.62 ± 0.26 times faster than grep "Exception" HUGE.log
なぜ ripgrep はこんなに速いのか?
巨大ファイルであればあるほど、ripgrep の設計思想が活きてきます。
- Rustによる高速な実装: Rust言語の安全かつ高速な特性を最大限活用しています。
-
マルチコア並列処理: 標準の
grepが1つのコアで愚直に読み込むのに対し、ripgrepはファイルをメモリマップし、複数のCPUコアで並列にスキャンします。 - SIMDの活用: 一度の命令で複数のデータを同時に処理する「SIMD」を利用して、改行や検索文字を高速に見つけ出します。
まとめ
普段の業務ではなかなか感じることはありませんでしたが、40GBを超えるような巨大なデータは、ripgrepがなければ業務が立ち行かないレベルだったのでとても助かりました...
具体的な導入方法等は以下もご参照ください!
追記: 通常業務でも使うようにしましたがリポジトリ内の検索など意外と普段から色々なところでgrepしていたんだなと思い、その度に効果を実感しています。