Ah. I recommend adding a link to that FAQ entry in the README, as it currently mentions in several places that it has optional PCRE support but has zero mention of the fact that this is (usually) slower.
My extremely unscientific test had PCRE2 being quite a bit slower - 1 second vs 0.2 seconds to search through 10k files - ie, slower, but still pretty darn fast.
That feels like it's in about the right ballpark based on my own tests. You can make it go a bit faster if you're using nightly Rust and compile with SIMD optimizations:
In particular, this enables SIMD optimizations in the crate ripgrep uses for decoding UTF-8, which is required to run on all files in order to use PCRE2 in Unicode mode.
(Eventually, I'm hoping the SIMD optimizations in the encoding_rs crate move to using runtime detection like the regex crate instead of requiring compile time flags.)
Or alternatively, disable Unicode with `--no-pcre2-unicode` and no transcoding will be done. :-)
I've been using ag, the silver searcher, for a few years now. It's blazingly fast (easily searching a massive code base in single-digit seconds), automatically ignores files I almost never want to be searched (anything in .git for example), and has convenient defaults around color highlighting and showing context.
I'm more than open to add ripgrep to my collection of everyday tools, however, if there is a real benefit. Does ripgrep do anything that would replace or complement my ag usage?
Note that it may also be possible that for new users, ripgrep is the better tool, but that ag is still more than good enough if you already based workflows and habits around it.
ripgrep does everything you say about ag, and has much less buggy support for gitignore. It is also quite a bit faster for bigger workloads. For smaller work loads you might not notice a difference. However, ripgrep is good enough to even replace uses of grep where ag might otherwise behave sub-optimally.
Specifically, with this release, ag no longer has any major features that ripgrep doesn't have. Additionally, ripgrep gives you almost every flag found in GNU grep, and then some.
I think some of this is addressed in the README. :)
It'd be great if you'd go back and update your blog post https://blog.burntsushi.net/ripgrep/ now that so many of the "anti-pitch" bullets are fixed (and I can only assume that the numbers have changed in the last two years)
Yeah, I have been superficially updating that post, but haven't yet for the latest release.
Updating the benchmarks is harder because of the analysis. I would need to redo almost all of it, which took weeks. The TL;DR though is that ripgrep is faster than it was then. Other tools like ag and grep have roughly remained the same.
ripgrep is simply phenomenal. The rest of my team are stuck using IDEs where they can only look at one project at a time, where as I can structure them as I want and rg over them all.
> My hope is that this article not only convinced you that rg is quite fast, but more importantly, that you found my analysis of each benchmark educational. String searching is an old problem in computer science, but there is still plenty of work left to do to advance the state of the art.
I also use ag for years. Recently I tried to use rg and found it is even faster than ag. Few times I compared results and somehow ag skipped few files but rg found matches.
My reflexes are still to type ag but I already want to switch to rg.
alias ag="rg" is what I've just started doing. Both tools are great, but rg is just better and faster, while also not missing anything that ag has (at least from my own experience).
Just in case you were inclined discount burntsushi’s comment for [justified] pride, it’d be a mistake. I happily used ag for years but switched to ripgrep awhile back after seeing that everything worked a bit faster and better (i.e. I haven’t had to think about gitignore file parsing for at least a year). I don’t even have ag or ack installed anymore, after years of them being one of the first things I’d add to a new system.
I have also been a long-time ag user (including submitting some patches) and transitioned to rg with little effort. Both tools are great and I use them more or less interchangeably.
rg is faster. Handles unicode better. Could never get ag and others to fully respect .gitignore files properly either (had to specially craft dedicated rules for edge cases), this does it out of the box.
Plus, I like the regular updates and that you can also use parts of it (regex engine etc) as libraries for your own Rust programs.
`ack` has been my goto for grep-likes -- though I would occasionally `ag` for the multi-line support, which ack does not have. My favorite feature of ack that ag didn't have was the --output flag, which would let you do something like this:
$ ack '^(\w+)' --output 'hello $1 world'
hello abc world
hello defgh world
hello etc world
But seems like this is equivalent to rg's `-or` flag, so looks like I don't have any reason to not switch over. I love the `-r` flag by itself (short for `--replace`), which seems like a handy replacement for sed's substitution. Also, I've been impressed with how responsive and receptive the author has been on Github.
And it doesn't hurt that all of other burntsushi's tools seem solid and well-designed, such as xsv.
One of the first things i install on a new system. I gave it to a friend who's just learning to program and has a hard time organizing their projects still - it's been an absolute lifesaver.
Can you give a specific example? I'd be happy to try and work though it with you! ripgrep certainly supports .ignore files. Last I checked, ack specifically doesn't support .ignore files: https://beyondgrep.com/feature-comparison/
22 comments
[ 3.1 ms ] story [ 45.9 ms ] threadI'm curious what the performance implications of switching to PCRE2 are.
For performance, here's a start. :) https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcr...
(Eventually, I'm hoping the SIMD optimizations in the encoding_rs crate move to using runtime detection like the regex crate instead of requiring compile time flags.)
Or alternatively, disable Unicode with `--no-pcre2-unicode` and no transcoding will be done. :-)
Great work on ripgrep and thanks for such an amazing tool!
I'm more than open to add ripgrep to my collection of everyday tools, however, if there is a real benefit. Does ripgrep do anything that would replace or complement my ag usage?
Note that it may also be possible that for new users, ripgrep is the better tool, but that ag is still more than good enough if you already based workflows and habits around it.
Specifically, with this release, ag no longer has any major features that ripgrep doesn't have. Additionally, ripgrep gives you almost every flag found in GNU grep, and then some.
I think some of this is addressed in the README. :)
Updating the benchmarks is harder because of the analysis. I would need to redo almost all of it, which took weeks. The TL;DR though is that ripgrep is faster than it was then. Other tools like ag and grep have roughly remained the same.
> My hope is that this article not only convinced you that rg is quite fast, but more importantly, that you found my analysis of each benchmark educational. String searching is an old problem in computer science, but there is still plenty of work left to do to advance the state of the art.
My reflexes are still to type ag but I already want to switch to rg.
Plus, I like the regular updates and that you can also use parts of it (regex engine etc) as libraries for your own Rust programs.
And it doesn't hurt that all of other burntsushi's tools seem solid and well-designed, such as xsv.
[0]: https://github.com/mileszs/ack.vim