ハクソク

世界を動かす技術を、日本語で。

Ripgrepはgrep、ag、git grep、ucg、pt、siftよりも速い（2016年）

45日前原文(burntsushi.net)

概要

  • ripgrep はThe Silver Searcherの使いやすさとGNU grepの高性能を融合した新しいコマンドライン検索ツール
  • Rust製 でクロスプラットフォーム対応、Linux/Mac/Windows用バイナリ提供
  • Unicode完全対応 かつ高速性を維持、.gitignoreやファイルタイプ指定検索もサポート
  • 他の主要検索ツールとのベンチマーク比較 で性能・正確性の両面で優位性を主張
  • インストール方法や主な機能、使い方の概要 も解説

ripgrepの紹介

  • ripgrep は、The Silver Searcher（ackクローン）の使いやすさと、GNU grepの生のパフォーマンスを兼ね備えた新しいコマンドライン検索ツール
  • Rust製 であり、Linux・Mac・Windowsの各プラットフォーム向けにバイナリが提供
  • GitHub で公開されており、誰でも入手・利用可能
  • クロスプラットフォーム対応 により、開発現場での幅広い利用シーンに対応
  • Unicode完全対応 でありながら、検索速度を損なわない設計

ripgrepの主な特徴

  • 他の検索ツールを置き換える ことが可能な豊富な機能と高速性
  • デフォルトで再帰的ディレクトリ検索 を実施し、.gitignoreファイルを自動で考慮
  • 隠しファイルやバイナリファイルもデフォルトで除外 し、不要なノイズを排除
  • .gitignore完全対応 で、他ツールではバグが多い部分も正確に動作
  • ファイルタイプごとの検索・除外 が可能（例：Pythonファイルのみ、JavaScriptファイルを除外など）
  • カスタムファイルタイプ定義 にも対応し、柔軟な運用が可能
  • grep同等の機能 （検索結果の前後文脈表示、複数パターン検索、色付きハイライト、Unicode完全対応）
  • PCRE2による正規表現拡張 （look-aroundや後方参照など）もオプションで利用可能
  • UTF-8以外のエンコーディング （UTF-16, latin-1, GBK, EUC-JP, Shift_JIS等）にも対応
  • 圧縮ファイル内検索 （gzip, xz, lzma, bzip2, lz4）も可能
  • 任意の入力前処理フィルタ （PDFテキスト抽出、追加のデコード等）もサポート

ripgrepの弱点・利用を控えるべき理由

  • POSIX準拠や普及率が必要な場合 は、従来のgrepが推奨
  • 他ツール特有の機能やバグに依存 している場合、ripgrepでは代替不可の場合もあり
  • 特殊なパフォーマンス要件やエッジケース で他ツールが優れる場合も存在
  • インストール困難な環境や未対応プラットフォーム では利用不可

ripgrepのインストール方法

  • バイナリ名はrg
  • Windows/Mac/Linux向けバイナリ が公式で配布
    • Linux: 静的バイナリ
    • Windows: MinGW（GNU）版とMSVC版、MSVC推奨（VC++ 2015ランタイム必要）
  • Homebrewユーザー: brew install ripgrep
  • Archlinuxユーザー: pacman -Syu ripgrep
  • Rustプログラマー: cargo install ripgrep
  • ソースからビルド: Rust 1.9以上が必要、cargo build --releaseでビルド可能
    • SIMDアクセラレーションもnightly Rustで有効化可能

ripgrepのクイックツアー

  • コマンドライン操作感 は他ツールとほぼ同じ
  • 端末出力時は自動で色付け・行番号表示 （Windowsでも対応）
  • 入力ファイルは基本的にUTF-8前提 だが、UTF-16は自動判別、他は-E/--encodingで指定
  • 再帰的検索・.gitignore考慮・隠し/バイナリ除外: rg foobar
  • 全てのファイルを検索: rg -uuu foobar
  • 大文字小文字無視: -i、 否定検索: -v、 前後文脈表示: -C2
  • 単語単位での一致: -w
  • 検索＆置換機能: --replaceオプション
  • ファイルグロブ指定: -gオプション
  • 特定ファイルタイプのみ/除外: -t/-Tオプション
  • ファイルタイプ追加: --type-add
  • 正規表現構文 はRustのregexライブラリ準拠

grep系検索ツールの構造とripgrepの位置付け

  • grep系: 指定ファイルのみ検索、-rで再帰検索
  • ack系: デフォルトで再帰検索、不要ファイル・ディレクトリ自動除外
  • ripgrep: grepの大規模ファイル対応とackのスマートなデフォルト検索を両立
  • git grep: ack系のようにバージョン管理下ファイルのみ検索

ベンチマークとパフォーマンス比較

  • 25種類のベンチマーク で主要検索ツールと比較
    • 単一ファイル・巨大ディレクトリの両方でripgrepが性能・正確性で優位
    • Unicode対応と速度の両立 はripgrep独自
    • メモリマップ利用ツールは多ファイル検索時に一般的に遅い
  • パフォーマンスに疑問がある場合は再現可能なケースでissue投稿を推奨

まとめ

  • ripgrep は、速度・機能・Unicode対応・柔軟性のバランスが秀逸な検索ツール
  • コマンドライン作業やコード検索の効率化 に最適
  • 他ツールの長所も吸収しつつ独自の強みを発揮
  • インストールも簡単 で、幅広い環境に対応
  • より詳細な情報やFAQは公式GitHubリポジトリを参照

Hackerたちの意見

(2016)

└

振り返ってみると、最初のRustの「キラーアプリ」かもね。

一度ripgrepを使ってた時に、恐ろしいバグにハマったことがあって…何だったかは思い出せないけど、絶対にそこにあるはずのテキストが見つからなかったんだ。最終的には、マシンを完全に再構築しようかと思ったけど、長い間そのバグに悩まされた後に、普通のgrepを試したら、データがちゃんとそこにあったんだよね。あんまり具体的な話じゃないけど、昔のことだから詳細は覚えてないけど、パニックになったのは覚えてる。

└

それ、バグって確認されたの？たまにプロジェクトのCI用の設定ファイルがドットディレクトリの下にあることを忘れちゃって、rgがデフォルトで無視しちゃうから、そのサブディレクトリのパスを指定して検索し直さなきゃいけなくなるんだよね（.git以外のドットディレクトリを無視しないようにrgに追加のフラグを使うこともあるけど）。

└

そのファイル、.gitignoreに入ってたりしない？俺はホームフォルダをgitで管理してるから、ドットや設定ファイルを追跡してるんだけど、それにいつも引っかかっちゃう。gitが無視するファイルをデフォルトで無視するの、ほんと嫌だわ。

└

最近、俺もそんなことがあった…基本的にrg xは何も表示しないのに、grep -r xはxの行を表示してくれた。いろんなxで何度も試したけど、その時はgrep -rを使い続けてた。数日後に再びrgを使い始めたら、ちゃんと動いたけど、今は確認のためにgrep -rもたまに使うようにしてる。

└

もしかしてテキストエンコーディングに関係ある？riggrepはデフォルトでUTF-16ファイルを検索しないと思う。少なくとも一度そんな問題があったことがある。

└

これがあなたの問題だったかは分からないけど、あまり明確じゃないから投稿するね（特にデフォルトの挙動について）： rg : gitで追跡されているファイルを検索 rg -u : .gitignoredファイルも含む rg -uu : .gitignored + 隠しファイルも含む rg -uuu : .gitignored + 隠し + バイナリファイルも含む

└

誤って推測されたエンコーディングスキームだったのかな？ptでもそれに遭遇したことがあって、確かに気が狂いそうになったよ。[0] rgが同じ問題を抱えてたかどうかは完全には覚えてない。

すごく面白い話だった。実はこの前、検索ツールを速くするために「最も一般的でないバイト」を探すアイデアを盗みに行ったんだ。https://github.com/boyter/cs これをfzfのsimd上限下限検索技術と組み合わせたら、実行時間が1/3になったよ。今日、cursorからの投稿で、ripgrepの制限に引っかかるエージェント用のインデックスを作る話があったけど、どのコードベースがそれに該当するのかは分からない。特に、100-200GBに達しないと15秒の実行時間にはならないからね。全てのマッチがそうなら別だけど。

└

うん、そのCursorのブログ記事はちょっと微妙だね。「ripgrepは大きなモノレポでは遅い」って部分を軽く流して、使ったテクニックに移って、インデックスを構築・維持しなきゃいけないってことを完全に無視してる。中規模のコードベースでは、fzfやrgでほぼ瞬時にコードを検索できたけど、同僚のPCはPycharmがプロジェクトの再インデックスを始めたら、めっちゃ遅くなってた。

週末にripgrepをIRIXに移植したばかりなんだ。300MHzのOctaneでも速いよ。

└

IRIXって今、趣味で復活してるの？ここ2日間で2回もIRIXの話を見たし、1、2日前にはVoodooのビデオカードの投稿もあったよね。2003年に働いてた会社以来、実際にIRIXを見たことないんだけど、SGIっていつもクールなイメージがあるけど、こんなにたくさん話題になるのは珍しいね。

└

Irixに戻すことについてのブログ記事を読みたいな！

HNの歴史の中で一番好きな瞬間の一つは、いろんな検索ツールの作者たちがそれぞれの".ignore"ファイルを持つのではなく、共通のものを決めるところを見たことだな。 https://news.ycombinator.com/item?id=12568245

└

.gitignoreを読み込むgrep系のツールは「最小驚愕の原則」（POLA）に反してると思う。そういう機能を有効にするための--ignoreフラグがあればいいけど、デフォルトでそれだとなんか違和感があるんだよね。もちろん、俺より賢い人たちは違う意見かもしれないけど、俺の頭はそう感じてる。

これ、何度も読んできたけど、やっぱりこの投稿が速いgrepライクなツールを作る問題について一番面白くて情報豊富だと思う。ripgrepの動作だけじゃなくて、他のツールの動作も説明して、いろんなテクニックを比較してるのがいいね。チュートリアルでもあり、専門的な深堀りでもある。ほんとに素晴らしい文章だよ。完璧な世界なら、すべてのコードが同じようにドキュメント化されてるはず。

なんでagから切り替えなかったかは覚えてないけど、意識的な決断だったのは確か。設定に関係してたと思う、rgが暗黙の'.ignore'ファイルを使ってる（ツール特有の設定じゃなくて超一般的な名前）か、.gitignoreのせいか、他にも使いづらい理由があった気がする。ほんとに思い出せないけど、使い方を調整するのに時間をかけすぎて、価値がないと判断したのは覚えてる。まあ、速いのはいいけど、agが遅すぎるとは感じたことないな。前のやつ（何だっけ？ack？）からの切り替えは劇的な改善に感じたけど、agとrgの違いは実際にはあまりなかった。

└

agから切り替えなかった、[...] rgが暗黙の'.ignore'ファイルを使ってる（ツール特有の設定じゃなくて超一般的な名前） 「.ignore」って名前は実際にagの作者が提案したもので、rgの作者はそれがあまりにも一般的すぎると思ってたんだよね。 https://news.ycombinator.com/item?id=12568245

└

なんでrgに切り替えたのか思い出そうとしてたんだけど、いいツールだし満足してるけど、前のツールにも満足してたのを覚えてるんだよね（grepからackに移って、パフォーマンスのためにagに飛びついて、理由は忘れたけどptに行った感じ）。しばらくかかったけど、ptがいくつかのファイルのエンコーディングを間違って推測する問題にぶつかったのを思い出したよ。[0] それとrgが同じ問題を抱えてたかどうかは覚えてないけど、rgに切り替えてからはすごくスムーズにいってて、それ以来ずっと満足してる。

└

CMakeファイルを検索するためにagにフィルターを追加しようとしたんだけど、コードにかなりバカな設計上の問題があってできなかったんだ。それを修正するプルリクエストを書いたけど、メンテナーに無視されて、後で他の人も同じフィルターを書いてて無視されてたことに気づいた。

Claude Codeがgrepを使うとき、実際にはその下でrgを使ってるんだよね。

└

お、面白い！ユーザーから「grepじゃなくてrgを使え」っていう提案があったんだけど、rgを使うのがちょっとイラッとしたんだよね。

grepの構文と互換性がないから、ほとんどのシステム管理者には役に立たない。

ripgrepのことを初めて聞いたときは笑っちゃった。grepはもう確立されすぎてて、100%互換性がないものが流行るわけないって思ってた。でも、完全に間違ってた。あっという間にみんなrgを使うようになった（俺も含めて）。