3 ms·

> Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. grep will try to search

> Like, searching for `isLoading` on my frontend (~3444 files) is instant with rg (less than 0.10s) but takes a few minutes with grep. grep will try to search inside .git. If your project is Javascript, it might be searching inside node_modules, or .venv if Python. ripgrep ignores hidden files, .gitignore and .ignore. You could try using `git grep` instead. ripgrep will still be faster, but the difference won't be as dramatic.

maeln 1y ago
No i specifically made sure to run it in a dir without a .git, node_modules, etc. It is just that slow
burntsushi 1y ago
While sometimes a plausible explanation for huge differences in search time, there are at least two other possible explanations. First is parallelism. If you do `grep -r`, most greps (like GNU grep and BSD grep and the one found on macOS) will not use parallelism. ripgrep will. This could easily account for a large perceived difference in search time. Second is the grep implementation. While GNU grep is generally considered to be quite fast on its own (especially in the POSIX locale), many other grep implementations are not. And indeed, they may be extraordinarily slow. For example, consider this comparison between FreeBSD grep (on macOS) and ripgrep (I clipped the `time` output for the `wc -l` command, which I just used to make the output smaller): $ time rg -j1 -uuu -w -g '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 0.769 user 0.105 sys 0.662 maxmem 5104 MB faults 0 $ time LC_ALL=C grep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 15.830 user 14.576 sys 1.253 maxmem 2224 MB faults 1 $ time LC_ALL=C ggrep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 1.148 user 0.206 sys 0.767 maxmem 2784 MB faults 1 This is just a straight up comparison that removes things like parallelism and filtering completely. This is purely algorithms. And the difference is an order of magnitude. Any one of these explanations, on its own, can account for huge differences in perceived performance. It's not really possible to know which one (perhaps even all 3) is relevant from pithy descriptions of ripgrep being so much faster than other tools. Version info for above commands: $ rg --version ripgrep 14.1.1 (rev bb88a1ac45) features:+pcre2 simd(compile):+NEON simd(runtime):+NEON PCRE2 10.45 is available (JIT is available) $ grep -V grep (BSD grep, GNU compatible) 2.6.0-FreeBSD $ ggrep -V ggrep (GNU grep) 3.12 Packaged by Homebrew Copyright (C) 2025 Free Software Foundation, Inc. [.. snip ..]

maeln 1y ago

No i specifically made sure to run it in a dir without a .git, node_modules, etc. It is just that slow

burntsushi 1y ago

While sometimes a plausible explanation for huge differences in search time, there are at least two other possible explanations. First is parallelism. If you do `grep -r`, most greps (like GNU grep and BSD grep and the one found on macOS) will not use parallelism. ripgrep will. This could easily account for a large perceived difference in search time. Second is the grep implementation. While GNU grep is generally considered to be quite fast on its own (especially in the POSIX locale), many other grep implementations are not. And indeed, they may be extraordinarily slow. For example, consider this comparison between FreeBSD grep (on macOS) and ripgrep (I clipped the `time` output for the `wc -l` command, which I just used to make the output smaller): $ time rg -j1 -uuu -w -g '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 0.769 user 0.105 sys 0.662 maxmem 5104 MB faults 0 $ time LC_ALL=C grep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 15.830 user 14.576 sys 1.253 maxmem 2224 MB faults 1 $ time LC_ALL=C ggrep -E -w -r --include '*.c' '[A-Z]{2}_RESUME' | wc -l 22 real 1.148 user 0.206 sys 0.767 maxmem 2784 MB faults 1 This is just a straight up comparison that removes things like parallelism and filtering completely. This is purely algorithms. And the difference is an order of magnitude. Any one of these explanations, on its own, can account for huge differences in perceived performance. It's not really possible to know which one (perhaps even all 3) is relevant from pithy descriptions of ripgrep being so much faster than other tools. Version info for above commands: $ rg --version ripgrep 14.1.1 (rev bb88a1ac45) features:+pcre2 simd(compile):+NEON simd(runtime):+NEON PCRE2 10.45 is available (JIT is available) $ grep -V grep (BSD grep, GNU compatible) 2.6.0-FreeBSD $ ggrep -V ggrep (GNU grep) 3.12 Packaged by Homebrew Copyright (C) 2025 Free Software Foundation, Inc. [.. snip ..]