I have been using ag for more than a decade and is an invaluable tool formmenwith probably dozens of invocations per day.
However “beating grep” in all these tools, usually lacks the important “at specific tasks”.
Ack, which to my knowledge was the first among this family of tools, claims this very clearly in their website. They made design choices optimized for code search and warn that the tool is not intended as a replacement for grep.
Grep is reliable, trustable, well documented, battle tested and feature rich. While still being a tool with a well defined specific scope.
While these newer tools can show you the results faster than grep in most cases, grep is still relatively fast and it was the fastest search tool for more than a decade before these tools exist. It also is well behaved in terms of resource usage.
It still is faster than naive search tools such as those found in text editors.
If I had to choose a search program and one only, I would still pick grep.
I use it extensively in shellscripts for filtering and string extraction because pretty much every system includes it.
i occasionally try some of these new “beating grep” tools and I always return to ag without fail. i love its ergonomics and it’s more than swift enough for me :)
Andreas Fredriksson - Context is Everything is a pretty concise talk about making a custom parser faster (so, not exactly the same thing but still interesting, and it made me miss the profiling part in this post).
Thanks for the suggestion. I ran grep with LC_ALL=C in both tests and it made it quicker by ~1 second in both.
My understanding is that setting this removes Unicode support and forces grep to use ASCII. This might be unfair to the other search tools – I’ll dig into this more and may/may not add a note about it.
IIRC you can switch off unicode support in rg, but it’s definitely “cheating” to me, as you normally really want to be able to parse the “universal” encoding standard.
The Grep family is one of those tools I always lose competency with after a few months. I only reliably use it for simple searches and exclusions on STDIN.
I can never remember the difference between grep, egrep, fgrep, and how those versions differ between GNU grep and BSD (macOS) grep. It’s the same with sed - trying to keep invocations straight between the BSD and GNU variants means I remember neither effectively. find to a lesser extent.
I am very, very happy that ripgrep and fd solved searching file contents and file names for me. Is there a similar replacement for sed? Or a more general modern tool for recursive find-replace file editing on a directory tree? That task is often the sole reason I open an IDE.
I never use egrep or fgrep. From my perspective, these look like relics of the past that almost nobody usea anymore.
Grep does search into multiple files and has support for PCRE.
But yeah, there are BSD and macOS versions of grep that share the name but their utility and performance are not to be compared. They don’t even have support for PCRE, which I use 50% of the time.
I was curious if gnu grep would behave differently than bsd grep and then actually tried git grep since it can be used as a git-repo-less grep replacement and was quite surprised by the outcome!
hyperfine -L cmd 'rg -uuu -n','git grep --no-index --exclude-standard -F -r -n' '{cmd} packages/react-fetch react' --warmup=1 --export-markdown cmp.md
Benchmark 1: rg -uuu -n packages/react-fetch react
Time (mean ± σ): 261.1 ms ± 1.5 ms [User: 471.3 ms, System: 1786.7 ms]
Range (min … max): 258.1 ms … 263.0 ms 11 runs
Benchmark 2: git grep --no-index --exclude-standard -F -r -n packages/react-fetch react
Time (mean ± σ): 16.7 ms ± 0.6 ms [User: 12.5 ms, System: 52.8 ms]
Range (min … max): 15.3 ms … 18.8 ms 163 runs
Summary
'git grep --no-index --exclude-standard -F -r -n packages/react-fetch react' ran
15.65 ± 0.56 times faster than 'rg -uuu -n packages/react-fetch react'
I have been using ag for more than a decade and is an invaluable tool formmenwith probably dozens of invocations per day.
However “beating grep” in all these tools, usually lacks the important “at specific tasks”.
Ack, which to my knowledge was the first among this family of tools, claims this very clearly in their website. They made design choices optimized for code search and warn that the tool is not intended as a replacement for grep.
Grep is reliable, trustable, well documented, battle tested and feature rich. While still being a tool with a well defined specific scope. While these newer tools can show you the results faster than grep in most cases, grep is still relatively fast and it was the fastest search tool for more than a decade before these tools exist. It also is well behaved in terms of resource usage. It still is faster than naive search tools such as those found in text editors.
If I had to choose a search program and one only, I would still pick grep.
I use it extensively in shellscripts for filtering and string extraction because pretty much every system includes it.
i occasionally try some of these new “beating grep” tools and I always return to
agwithout fail. i love its ergonomics and it’s more than swift enough for me :)Andreas Fredriksson - Context is Everything is a pretty concise talk about making a custom parser faster (so, not exactly the same thing but still interesting, and it made me miss the profiling part in this post).
When testing things like that please check with LC_ALL=C. You may get 6x gain for grep and it may get very comparable to grup.
Thanks for the suggestion. I ran
grepwithLC_ALL=Cin both tests and it made it quicker by ~1 second in both.My understanding is that setting this removes Unicode support and forces
grepto use ASCII. This might be unfair to the other search tools – I’ll dig into this more and may/may not add a note about it.IIRC you can switch off unicode support in rg, but it’s definitely “cheating” to me, as you normally really want to be able to parse the “universal” encoding standard.
Interesting, how come grep didn’t add OpenMP support yet.
For regular use of grep without regex I can recommend using the faster and standardized
grep -F(on most systems also availabe as the aliasfgrep).The Grep family is one of those tools I always lose competency with after a few months. I only reliably use it for simple searches and exclusions on STDIN.
I can never remember the difference between grep, egrep, fgrep, and how those versions differ between GNU grep and BSD (macOS) grep. It’s the same with
sed- trying to keep invocations straight between the BSD and GNU variants means I remember neither effectively.findto a lesser extent.I am very, very happy that ripgrep and fd solved searching file contents and file names for me. Is there a similar replacement for
sed? Or a more general modern tool for recursive find-replace file editing on a directory tree? That task is often the sole reason I open an IDE.I never use egrep or fgrep. From my perspective, these look like relics of the past that almost nobody usea anymore.
Grep does search into multiple files and has support for PCRE.
But yeah, there are BSD and macOS versions of grep that share the name but their utility and performance are not to be compared. They don’t even have support for PCRE, which I use 50% of the time.
I use sd all the time and I love it.
I was curious if gnu grep would behave differently than bsd grep and then actually tried git grep since it can be used as a git-repo-less grep replacement and was quite surprised by the outcome!
Can it beat ripgrep, though? (I already know the answer)
https://github.com/Genivia/ugrep claims to be the fastest
Impressive