ripgrep im Detail: rekursive Codesuche mit gitignore-Filter und ihre Leistungsklippen

rg -uuu: die Automatikfilter von ripgrep und wie man sie abschaltet

ripgrep, im Terminal als rg aufgerufen, ist ein zeilenorientiertes Suchwerkzeug, das das aktuelle Verzeichnis rekursiv nach einem Regex-Muster durchsucht. Das Besondere liegt in der Voreinstellung. Standardmäßig respektiert rg die Regeln der .gitignore-Datei, überspringt versteckte Dateien und Verzeichnisse und lässt binäre Inhalte aus. Wer diese gesamte automatische Filterung ausschalten will, erreicht das mit rg -uuu.

Genau dadurch löst das Werkzeug ein praktisches Problem: Suchläufe in großen Repositories treffen auf Dateisammlungen, die ohnehin ausgeschlossen sind, und tragen sie nicht nutzlos durch die Ergebnismenge. Das README ordnet ripgrep neben The Silver Searcher, ack und grep ein und beansprucht erstklassige Unterstützung für Windows, macOS und Linux, mit vorkompilierten Binärpaketen zu jeder Ausgabe. Die aktuelle Version 15.2.0 erschien im Juli 2026, lizenziert ist das Projekt dual unter MIT oder der Unlicense. Rund 67.670 Sterne und 2.744 Forks zeigen die Verbreitung; 182 Issues sind offen.

rg -tpy, -Tjs und PCRE2: Muster gezielt durch den Quellbaum lenken

Über die bloße Mustersuche hinaus kennt rg Dateitypfilter. Der Aufruf rg -tpy foo begrenzt die Suche auf Python-Dateien, rg -Tjs foo schließt JavaScript aus, und neue Typen lassen sich dem Werkzeug beibringen. Dazu kommen Kontextzeilen, mehrere Muster in einem Lauf und farbige Hervorhebung der Treffer.

Für anspruchsvollere Ausdrücke aktiviert -P beziehungsweise --pcre2 die PCRE2-Engine, die Lookarounds und Rückverweise erlaubt, die die eingebaute Rust-Regex-Engine nicht kennt; --auto-hybrid-regex wählt zwischen beiden Engines automatisch, --engine bietet eine alternative Syntax. Kodierungen fremder Formate stellt -E/--encoding ein, etwa UTF-16, latin-1, GBK, EUC-JP oder Shift_JIS. Mit -z/--search-zip durchsucht rg komprimierte Archive, laut README unter anderem brotli, bzip2, gzip, lz4, lzma, xz und zstandard. Auch Eingabe-Vorverarbeitungsfilter und eine Konfigurationsdatei sind dokumentiert; deren Syntax erklärt der Benutzerleitfaden GUIDE.md, nicht das README selbst.

Kernel-Baum und 13GB-Datei: die selbst berichteten Benchmarks von ripgrep

Das README enthält mehrere Benchmark-Tabellen, erhoben laut eigener Angabe auf einem System mit Intel i9-12900K bei 5,2 GHz. Im Linux-Kernel-Quellbaum, nach make defconfig && make -j8, fand rg -n -w '[A-Z]+_SUSPEND' 536 Zeilen in 0,082s. hypergrep brauchte 0,167s, git grep mit PCRE 0,273s, The Silver Searcher 0,443s, ugrep 0,639s und ack 2,935s bei 2.677 gefundenen Zeilen. Ein zweiter Lauf ohne gitignore-Filterung, rg -uuu -tc -n -w '[A-Z]+_SUSPEND', endete nach 0,063s gegen 0,607s für ugrep und 0,674s für GNU grep.

Auf einer einzelnen, rund 13GB großen und im Speicher gecachten Datei (OpenSubtitles, dekomprimiert) brauchte rg -w 'Sherlock [A-Z]\w+' 1,042s, ugrep 1,339s und GNU egrep mit Unicode 6,577s. Der Zusatz -n erhöhte die Zeiten auf 1,664s für ripgrep und 9,484s für GNU grep, während ugrep unbeeinflusst blieb. Alle Zahlen stammen vom Projekt selbst, und das README warnt ausdrücklich, dass ein einzelner Benchmark nie ausreicht, und verweist auf einen Blogbeitrag mit breiterer Analyse.

Wo rg einbricht: [A-Za-z]{30} und die Leistungsklippen

Ehrlicherweise zeigt das README auch, wo die Geschwindigkeit zusammenbricht. Für Muster ohne Chancen auf Literal-Optimierung, etwa rg '[A-Za-z]{30}' auf derselben 13GB-Datei, brauchte rg 15,569s, ugrep 21,857s und GNU grep mit LC_ALL=C 32,409s; GNU grep mit Unicode brauchte 8 Minuten und 30 Sekunden, das 32,74-Fache.

Hohe Trefferzahlen gleichen die Werkzeuge ebenfalls an. rg the fand 83.499.915 Zeilen in 6,948s, ugrep in 11,721s und GNU grep in 15,217s. Die Erklärung im README: Bei Millionen Treffern dominiert die Verarbeitung jedes einzelnen Treffers die Zeit, nicht der Erkennungsalgorithmus. Für die eigene Einschätzung zählt genau diese Seite des Bildes; wer viel mit breiten Mustern arbeitet, sollte die Klippen auf dem eigenen Korpus nachmessen, bevor er Umstellungen auf rg vornimmt.

SIMD, RegexSet und crossbeam: womit rg seine Geschwindigkeit erreicht

Das README führt die Geschwindigkeit auf konkrete Bausteine zurück. Die Rust-Regex-Engine arbeitet mit endlichen Automaten, SIMD und aggressiven Literal-Optimierungen. UTF-8-Dekodierung ist direkt in die deterministische Automaten-Engine eingebaut, wodurch Unicode-Unterstützung ohne die Bremsen bleibt, die das README dem Unicode-Modus von GNU grep zuschreibt.

Beim Einlesen wählt rg laut README automatisch zwischen Speicher-Mappings, die für einzelne Dateien besser passen, und inkrementell gepufferter Suche, die bei großen Verzeichnissen vorteilhaft ist. Die Ignorier-Muster aus den .gitignore-Dateien werden über ein RegexSet angewendet, sodass ein Dateipfad einmalig gegen mehrere Glob-Muster geprüft wird. Der parallele rekursive Verzeichnis-Iterator stammt aus den Crates crossbeam und ignore und arbeitet ohne Sperren. Das sind die Darstellungen des Projekts; dieser Artikel kann sie nicht unabhängig nachmessen.

cargo build --release und cargo test --all: ripgrep selbst bauen

Wer bauen will, braucht mindestens Rust 1.96.0; das Projekt folgt dem jeweils neuesten stabilen Release. Der Release-Bau läuft über cargo build --release, PCRE2-Unterstützung kommt mit cargo build --release --features 'pcre2' hinzu. Unter Linux lässt sich mit dem MUSL-Ziel eine vollständig statische Binärdatei erzeugen. Die Testsuite deckt laut README Unit- und Integrationstests ab und läuft mit cargo test --all aus dem Wurzelverzeichnis des Repositorys.

Alternativ installiert cargo install ripgrep direkt aus crates.io, cargo binstall wird als weitere Route genannt. Vorkompilierte Archive gibt es zu jeder Version auf der Releases-Seite. Das README weist noch auf eine Eigenheit hin: Die Binärdatei kann größer ausfallen als erwartet, weil sie absichtlich Debugsymbole enthält; strip verkleinert sie.

Wann grep bleibt: die eigenen Gegenargumente im ripgrep-README

Selten listet ein Werkzeug selbst Gründe auf, es nicht zu verwenden, und genau das tut das README. Wer ein portables, überall verfügbares Werkzeug braucht, wird bei grep bleiben, denn ripgrep erfüllt weder POSIX noch einen anderen Standard. Wer auf eine Funktion oder einen Bugfix in einem anderen Suchwerkzeug angewiesen ist, den das README nicht nennt, hat ebenfalls einen Grund zu bleiben.

Zwei weitere Einschränkungen räumt das Projekt ein. Es gibt Leistungsklippen, in denen ein anderes Werkzeug schneller ist; in solchen Fällen bittet es um Fehlerberichte. Und wenn sich ripgrep auf einer Maschine gar nicht installieren lässt oder die Plattform fehlt, hilft die beste Engine nichts. Die genannten Vergleichskandidaten, The Silver Searcher, ack, ugrep und hypergrep, decken jeweils andere Nischen ab; die Wahl hängt am konkreten Einsatzzweck, nicht an der Tabelle.

Redaktionelles Fazit

ripgrep passt für Entwickler, die in großen Quellbäumen nach Mustern suchen und die automatische Filterung über .gitignore, .ignore und .rgignore als Voreinstellung wollen; es passt nicht, wo POSIX-Verhalten von grep verlangt wird. Vor dem Wechsel lohnt ein eigener Testlauf: rg mit einer Musterwahl wie [A-Za-z]{30} auf dem eigenen Korpus ausführen, die Zeiten mit und ohne -n vergleichen und prüfen, ob die eigene Plattform in den Release-Artefakten von Version 15.2.0 abgedeckt ist.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes