Ripgrep vs Grep: Benchmark Nyata di 14.673 Berkas

Pada pengukuran langsung di repositori toolkuy (Ubuntu 24.04.5 LTS, kernel 6.8.0-147, ripgrep 14.1.0, GNU grep 3.11), ripgrep menyelesaikan pencarian string useState di 14.673 berkas node_modules dalam 0,12 sampai 0,14 detik saat cache sistem sudah hangat, sedangkan grep membutuhkan 0,46 sampai 1,44 detik. Selisih run terbaiknya sekitar 3,3 kali. Tetapi di direktori kecil berisi 69 berkas, grep justru tiga kali lebih cepat karena overhead start-up ripgrep lebih besar daripada pekerjaan yang harus diselesaikan.

TL;DR

• Di 14.673 berkas, ripgrep 0,14 detik melawan grep 0,46 detik pada run hangat, sekitar 3,3 kali lebih cepat.
• Di 69 berkas, grep 0,005 detik melawan ripgrep 0,017 detik, jadi grep menang untuk pencarian kecil.
• Jumlah hasil berbeda karena ripgrep menghormati .gitignore: 1.108 baris lawan 2.041 baris di direktori src.
• Dengan flag --no-ignore, kedua alat mengembalikan 2.041 baris yang identik, jadi tidak ada hasil yang hilang.
• Aturan praktisnya bukan mana yang lebih modern, melainkan seberapa besar pohon berkas yang dicari.

Mengapa jumlah hasil ripgrep dan grep berbeda?

Ripgrep secara bawaan menghormati .gitignore, melewati direktori tersembunyi, dan tidak membaca berkas biner, sementara grep membaca apa pun yang diberikan padanya. Pada direktori src repositori toolkuy yang berisi 69 berkas, ripgrep mengembalikan 1.108 baris cocok untuk kata import, sedangkan grep mengembalikan 2.041 baris. Ketika perintah yang sama dijalankan dengan flag --no-ignore, ripgrep juga mengembalikan tepat 2.041 baris, jadi selisihnya murni soal cakupan berkas, bukan soal mesin pencariannya.

Perbedaan ini penting karena banyak orang menyimpulkan ripgrep tidak menemukan sesuatu padahal berkasnya memang diabaikan oleh .gitignore. Artefak build, hasil generate, dan direktori vendor sering masuk daftar ignore, sehingga pencarian yang lewat ripgrep terasa lebih cepat bukan hanya karena algoritmanya, tetapi juga karena jumlah berkas yang dibacanya lebih sedikit. Untuk audit keamanan atau pencarian jejak kredensial, kebiasaan yang lebih aman adalah menambahkan --no-ignore dan --hidden supaya cakupannya sama dengan grep.

Berapa selisih waktu di direktori kecil dan direktori besar?

Selisihnya berbanding terbalik dengan ukuran pohon berkas: pada direktori kecil grep lebih cepat, pada direktori besar ripgrep meninggalkan grep. Setiap run diulang tiga kali dengan pola pencarian yang sama, dan angka di bawah adalah rentang yang terukur, bukan perkiraan.

Skenario	ripgrep 14.1.0	GNU grep 3.11	Catatan
src/ berisi 69 berkas	0,017 sampai 0,024 detik	0,004 sampai 0,007 detik	grep 3 sampai 5 kali lebih cepat
node_modules 14.673 berkas, run pertama	1,692 detik	3,664 detik	keduanya membayar biaya cold cache
node_modules, run hangat	0,117 sampai 0,140 detik	0,464 sampai 1,437 detik	ripgrep sekitar 3,3 kali lebih cepat
Jumlah hasil di src/	1.108 baris	2.041 baris	berbeda karena .gitignore
Jumlah hasil di src/ dengan --no-ignore	2.041 baris	2.041 baris	identik

Ada satu detail yang jarang disebut: grep mencetak peringatan binary file matches ketika menemukan pola di dalam berkas .node milik paket native seperti rolldown dan compiler Astro. Ripgrep tidak mencetak peringatan itu karena berkas biner dilewati secara bawaan. Pada pencarian kode sehari-hari perilaku ini lebih nyaman, tetapi pada pencarian forensik berkas biner justru bisa berisi jejak yang dicari, jadi flag tambahan tetap perlu disebut eksplisit.

Kapan sebaiknya tetap memakai grep?

Grep tetap pilihan yang benar ketika pencarian berjalan di lingkungan minimal, di dalam skrip yang harus portabel, atau pada pohon berkas yang kecil. GNU grep 3.11 tersedia di hampir setiap distribusi Linux, termasuk image container paling ramping, sedangkan ripgrep harus dipasang lebih dulu. Biaya start-up ripgrep di mesin uji ini sekitar 10 sampai 17 milidetik, dan pada pencarian satu berkas atau beberapa berkas biaya itu lebih besar daripada waktu kerja yang dihemat.

Grep juga lebih tepat ketika hasilnya akan diolah lanjutan oleh alat lain yang bergantung pada perilaku POSIX, misalnya keluaran -o, -c, atau -l yang dipakai di dalam pipeline panjang. Menukar grep dengan ripgrep di tengah pipeline tanpa menguji ulang seluruh rantainya berisiko, karena walaupun banyak flag-nya mirip, cakupan berkas dan perilaku terhadap berkas biner tetap berbeda.

Kapan ripgrep lebih masuk akal?

Ripgrep lebih masuk akal ketika pencarian menyentuh puluhan ribu berkas, ketika hasilnya dibaca manusia, dan ketika kecepatan interaktif menentukan alur kerja. Pada kasus node_modules di atas, perbedaan 0,14 detik melawan 0,46 detik terasa kecil untuk satu kali pencarian, tetapi pada 50 kali pencarian dalam satu sesi debugging selisihnya menjadi sekitar 16 detik yang tidak perlu dibuang.

Ripgrep juga unggul untuk pencarian bertipe, karena mendukung tipe berkas langsung seperti --type py atau --type rust, serta menampilkan nomor baris dan judul berkas secara rapi tanpa flag tambahan. Ketika bekerja di repositori besar yang isinya campuran dokumentasi, kode, dan aset, kombinasi kecepatan dan keluaran yang mudah dibaca itu yang membuat ripgrep lebih sering dipilih.

Bagaimana cara mereproduksi benchmark ini?

Seluruh angka di artikel ini dihasilkan dari perintah di bawah, dijalankan pada mesin yang sama dengan direktori kerja /srv/web/toolkuy. Untuk hasil yang bisa dibandingkan, jalankan berulang dan catat rentangnya, bukan satu angka.

cd /srv/web/toolkuy
TIMEFORMAT='%3R'
find src -type f | wc -l
find node_modules -type f | wc -l
for i in 1 2 3; do time rg -n 'import' src >/dev/null; done
for i in 1 2 3; do time grep -rn 'import' src >/dev/null; done
rg -n 'import' src | wc -l
grep -rn 'import' src | wc -l
rg -n --no-ignore 'import' src | wc -l

Untuk pohon besar, ganti src dengan node_modules dan gunakan pola yang jarang muncul, misalnya useState, supaya waktu yang terukur didominasi pembacaan berkas dan bukan pencetakan hasil ke terminal. Menulis keluaran ke /dev/null juga penting, karena terminal yang lambat bisa membuat alat yang lebih cepat terlihat lebih lambat.

Hal apa yang paling sering salah saat membandingkan keduanya?

Kesalahan paling sering adalah membandingkan dua alat dengan cakupan berkas yang berbeda lalu menyimpulkan salah satunya lebih cepat. Ketika ripgrep melewati berkas yang di-ignore dan grep tidak, ripgrep memang membaca lebih sedikit berkas, sehingga kemenangannya sebagian berasal dari definisi pekerjaan yang lebih sempit. Cara mengujinya sederhana: jalankan ripgrep dengan --no-ignore pada pohon yang sama, lalu bandingkan jumlah baris hasilnya dengan grep.

Kesalahan kedua adalah mengukur hanya sekali. Pada uji ini run pertama ripgrep mencapai 1,692 detik dan run berikutnya 0,117 detik, selisih lebih dari sepuluh kali yang sepenuhnya berasal dari cache sistem berkas. Angka satu kali run tidak cukup untuk menyimpulkan apa pun, dan tiga run dengan rentang yang dilaporkan jauh lebih jujur daripada satu angka terbaik yang dipilih belakangan.

Bagaimana keduanya menangani berkas biner dan hasil yang sangat banyak?

Grep memberi tahu ketika sebuah pola ditemukan di dalam berkas biner, sedangkan ripgrep melewatinya tanpa pesan. Pada uji di node_modules, grep mencetak peringatan binary file matches untuk dua berkas kompilasi native, yaitu rolldown-binding.linux-x64-gnu.node dan astro.linux-x64-gnu.node, sementara ripgrep tidak menyebut keduanya. Untuk pencarian kode sehari-hari perilaku ripgrep lebih nyaman karena keluarannya tidak dipenuhi peringatan yang tidak bisa dibaca manusia.

Perbedaannya bukan soal mana yang lebih benar, melainkan soal asumsi bawaan. Grep menganggap semua yang diberikan sebagai teks sampai terbukti sebaliknya, sehingga berkas biner tetap dibaca dan hasilnya dilaporkan. Ripgrep menganggap berkas biner sebagai noise kecuali diminta secara eksplisit, sehingga cakupannya lebih sempit tetapi lebih cepat. Pada audit yang mencari jejak kredensial di dalam arsip atau berkas hasil kompilasi, asumsi grep justru lebih aman.

Untuk hasil yang sangat banyak, keduanya punya batas yang mirip: waktu habis di terminal, bukan di mesin pencari. Menulis keluaran ke berkas lalu menghitungnya dengan wc -l memberi angka yang stabil, sedangkan membiarkan hasil tercetak ke terminal membuat alat yang lebih cepat terlihat sama lambatnya. Pada uji 14.673 berkas ini, seluruh keluaran diarahkan ke /dev/null supaya waktu yang terukur benar-benar mencerminkan pekerjaan pencarian, bukan pekerjaan menggambar teks di layar.

Kebiasaan lain yang membantu adalah membatasi hasil dengan flag jumlah maksimum saat sedang menjelajah kode. Ketika hanya butuh tahu apakah sebuah simbol masih dipakai, satu hasil pertama sudah cukup, dan sisa waktu bisa dipakai untuk membaca kode yang relevan. Pencarian yang menghasilkan 2.041 baris di direktori kecil seperti src biasanya bukan tanda alat yang hebat, melainkan tanda pola yang terlalu umum.

FAQ

Apakah ripgrep selalu lebih cepat daripada grep?

Tidak. Pada 69 berkas di direktori src, grep 3,11 menyelesaikan pencarian dalam 4 sampai 7 milidetik sedangkan ripgrep 14.1.0 butuh 17 sampai 24 milidetik. Biaya start-up proses ripgrep lebih besar, jadi untuk pencarian kecil grep tetap lebih cepat.

Kenapa hasil pencarian ripgrep lebih sedikit daripada grep?

Karena ripgrep secara bawaan menghormati .gitignore, melewati direktori tersembunyi, dan tidak membaca berkas biner. Tambahkan --no-ignore dan --hidden agar cakupannya setara; pada uji ini flag tersebut membuat jumlah hasil keduanya sama persis, yaitu 2.041 baris.

Apakah ripgrep bisa dipakai sebagai pengganti grep di dalam skrip shell?

Bisa, tetapi harus diuji ulang karena beberapa perilaku berbeda. Cakupan berkas, penanganan berkas biner, dan ketersediaan di sistem minimal adalah tiga hal yang paling sering menimbulkan kejutan saat skrip lama dipindahkan dari grep ke ripgrep.

Alat mana yang sebaiknya dipasang di server produksi?

Keduanya, karena biayanya kecil dan kegunaannya berbeda. Grep selalu ada sebagai jaring pengaman saat sistem baru dipasang, sedangkan ripgrep dipakai untuk pencarian interaktif pada repositori besar. Dokumentasi resmi ripgrep ada di repositori GitHub BurntSushi/ripgrep dan panduan pemakaiannya di GUIDE.md.

Di mana dokumentasi resmi GNU grep?

Manual lengkap GNU grep tersedia di situs GNU dan halaman manual sistem di man7.org. Keduanya menjelaskan flag -r, -o, -c, dan perilaku exit code yang sering dipakai di dalam skrip otomasi.