> 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.
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):
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:
No i specifically made sure to run it in a dir without a .git, node_modules, etc. It is just that slow