Live data from Hacker News

Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

blog.burntsushi.net

91–100 of 198 posts

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#91
And this may still be true in 2023, but the problem is that most of the parallelized grep replacements (e.g. ripgrep, ag, etc.) are SO much faster than grep that the much small speed differences between them doesn't provide much of a basis for differentiating them.

I use ag (typically from inside Emacs) on a 900k LOC codebase and it is effectively instantaneous (on a 16 core Ryzen Threadripper 2950X). I just don't have a need to go from less than 1 second to "a bit less than less than 1 second".

Speed is not the defining attribute of the "new greps" - they need to be assessed and compared in other ways.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#92

I can't think of a single time I've used grep where I thought "I wish this was faster".

Even if the answer is instant, you have a 50% performance improvement in your search just from typing "rg" instead of "grep"! From my perspective it's a no brainer. I don't HAVE a grep (because I don't have a Unix) so when I install a grep, any grep, reaching for rg is natural. It's modern and maintained. I have no scripts anywhere that might expect grep to be called "grep". Of course if you already have a grep (e.g.…

Even faster, I have an alias 'ss' (mnemonic for 'super search') for rg. Fitts' Law to the max!

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#93
post #60
post #30

Earlier quoted context omitted.

So I was casually searching for "ugrep vs ripgrep" articles, when I stumbled upon a couple reddit posts where apparently the authors of ugrep and ripgrep seemed to have a multi-year feud on reddit, eg. https://www.reddit.com/r/programming/comments/120wqvr/ripgre... So weird. I mean, it's just about some open source tool, right? :-/

This is so weird, even ripgrep's author is actively seeking conflict in ugrep's new release posts. Not a good colour on both of them.

Any examples? All I see in the recent release post is:

> ugrep is easily one of the if not most featureful grep programs in existence. And it is also fast.

which is burntsushi, ripgrep's author, defending ugrep from someone saying they only focus on performance at the cost of features.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#94
post #73

I messed up my conda environments once when I changed my username. So many references to the old username in the conda folders. Ripgrep saved the day!

Why not just make new ones? Regardless of whether I use Conda, Pyenv or virtualenv, I always consider the environments to be disposable.

It takes forever (like an hour) to install the data science stack plus pytorch and cuda libraries plus other hardware related libraries.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#95

Earlier quoted context omitted.

I hadn't heard of this before. Thanks!

Add one or a few drops of water to your roasted coffee beans with your hand and shake well after weighing it out to stop the grinds from sticking to the walls of your grinder from static.

This thread took a turn

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#96
post #62
post #3

It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…

I wrote a bash version of this: function frg { result=`rg --ignore-case --color=always --line-number --no-heading "$@" | fzf --ansi \ --color 'hl:-1:underline,hl+:-1:underline:reverse' \ --delimiter ':' \ --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \ --preview-window 'up,60%,border-bottom,+{2}+3/3,~3'` file="${result%%:*}" linenumber=`echo "${result}" | cut -d: -f2` if [ ! -z "…

I've never really seen PowerShell beyond minimal commands, but after seeing the parent, I definitely think it has the superior syntax of the shells. Especially for scripts.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#97
post #34

I switched from from ripgrep to ugrep and never looked back. It's just as fast, but also comes with fuzzy matching (which is super useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc. The optional Google search syntax also very convenient. https://ugrep.com

I’m a die-hard ripgrep fan, but just recently found ugrep looking for one feature that ripgrep lacks: searching in zip archives (without decompressing them to disk). Ugrep has that. In my case, I’m working with zipped corpora of millions of small text files, so I can skip unpacking the whole thing to the filesystem (certain filesystems have trouble at this scale). I’m grateful for both tools. Thanks to the respective…

That's where ripgrep-all comes into play which will grep through archives, PDFs, ebooks, documents, etc.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#98
I've been using ripgrep for about 2 years now and I find in indispensable. The main reason I switched from grep was ease of use. From the README: "By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files." Typing `rg search_term directory` is much better than the corresponding grep command, but the speed improvement is also a nice bonus.

Random other helpful flag I use often is -M if any of the matches are way too long to read through and cause a lot of terminal chaos. Just add `-M 1000` or adjust the number for your needs and the really long matches will omit the text context in the results.

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#99
post #62
post #3

It's fast indeed. And I can't help keeping promoting the combination with fzf :) For those who want to try it out, this is a Powershell function but the same principle applies in any shell. Does ripgrep then puts fuzzy searching in the resulting files+text on top while showing context in bat: function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color 'hl:-1:underl…

I wrote a bash version of this: function frg { result=`rg --ignore-case --color=always --line-number --no-heading "$@" | fzf --ansi \ --color 'hl:-1:underline,hl+:-1:underline:reverse' \ --delimiter ':' \ --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \ --preview-window 'up,60%,border-bottom,+{2}+3/3,~3'` file="${result%%:*}" linenumber=`echo "${result}" | cut -d: -f2` if [ ! -z "…

I wrote a zsh version of this:

  function frg {
      result=$(rg --ignore-case --color=always --line-number --no-heading "$@" |
        fzf --ansi \
            --color 'hl:-1:underline,hl+:-1:underline:reverse' \
            --delimiter ':' \
            --preview "bat --color=always {1} --theme='Solarized (light)' --highlight-line {2}" \
            --preview-window 'up,60%,border-bottom,+{2}+3/3,~3')
      file=${result%%:*}
      linenumber=$(echo "${result}" | cut -d: -f2)
      if [[ -n "$file" ]]; then
              $EDITOR +"${linenumber}" "$file"
      fi
    }

Re: Ripgrep is faster than grep, ag, Git grep, ucg, pt, sift (2016)

#100

And this may still be true in 2023, but the problem is that most of the parallelized grep replacements (e.g. ripgrep, ag, etc.) are SO much faster than grep that the much small speed differences between them doesn't provide much of a basis for differentiating them. I use ag (typically from inside Emacs) on a 900k LOC codebase and it is effectively instantaneous (on a 16 core Ryzen Threadripper 2950X). I just don't ha…

In 2016, I'd say speed was definitely a defining attribute. ag has very significant performance cliffs. You can see them in the blog post.

But as I mentioned in my comparison to qgrep elsewhere in the thread, everyone has different workloads. And for some workloads, perf differences might not matter. It really just depends. 900 KLOC isn't that big, and indeed, for simple queries pretty much any non-naive grep is going to chew through it very very quickly.

As for comparisons in other ways, at least for ag, it's on life support. I thought it was going to get removed from Debian, but it looks like someone rescued it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999962

The blog post also compares Unicode support, and contextualizes its performance. ag essentially has zero Unicode support. Unicode support isn't universally applicable of course---you may not care about it---but it satisfies your non-perf comparison criteria. :-)

Post reply on HN