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

It&#x27;s fast indeed. And I can&#x27;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:<p><pre><code> function frg { $result = rg --ignore-case --color=always --line-number --no-heading @Args | fzf --ansi ` --color &#x27;hl:-1:underline,hl+:-1:underline:reverse&#x27; ` --delimiter &#x27;:&#x27; ` --preview &quot;bat --color=always {1} --theme=&#x27;Solarized (light)&#x27; --highlight-line {2}&quot; ` --preview-window &#x27;up,60%,border-bottom,+{2}+3&#x2F;3,~3&#x27; if ($result) { &amp; ($env:EDITOR).Trim(&quot;`&quot;&#x27;&quot;) $result.Split(&#x27;: &#x27;)[0] } } </code></pre> There are other ways to approach this, but for me this is a very fast way of nailing down &#x27;I now something exists in this multi-repo project but don&#x27;t know where exactly nor the exact name&#x27;<p><i>edit</i> this comes out of <a href="https:&#x2F;&#x2F;github.com&#x2F;junegunn&#x2F;fzf&#x2F;blob&#x2F;master&#x2F;ADVANCED.md">https:&#x2F;&#x2F;github.com&#x2F;junegunn&#x2F;fzf&#x2F;blob&#x2F;master&#x2F;ADVANCED.md</a> and even though you might not want to use most of what is in there, it&#x27;s still worth glancing over it to get ideas of what you could do with it

I use ripgrep with the Emacs packages project.el (comes out of the box) and dumb-jump (needs to be installed). This may not be the most popular way of using rg but I have been very pleased with the overall experience. All it takes is running package-install to install the dumb-jump package and configuring the following hook:<p><pre><code> (add-hook &#x27;xref-backend-functions #&#x27;dumb-jump-xref-activate) </code></pre> The Xref key sequences and commands work fine with it. If I type M-. (or C-u M-.) to find definitions of an identifier in a Python project, dumb-jump runs a command like the following, processes the results, and displays the results in an Xref buffer.<p><pre><code> rg --color never --no-heading --line-number -U --pcre2 --type py &#x27;\s*\bfoo\s*=[^=\n]+|def\s*foo\b\s*\(|class\s*foo\b\s*\(?&#x27; &#x2F;path&#x2F;to&#x2F;git&#x2F;project&#x2F; </code></pre> The above command shows how dumb-jump automatically restricts the search to the current file type within the current project directory. If no project directory is found, it defaults to the home directory.<p>By the way, dumb-jump supports the silver searcher tool ag too which happens to be quite fast as well. If neither ag nor rg is found, it defaults to grep which as one would expect can be quite slow while searching the whole home directory.

What&#x27;s interesting is that ripgrep now also powers VS Code search with a Node.js wrapper.<p><a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;@vscode&#x2F;ripgrep" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;@vscode&#x2F;ripgrep</a>

I&#x27;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: &quot;By default, ripgrep will respect gitignore rules and automatically skip hidden files&#x2F;directories and binary files.&quot; Typing `rg search_term directory` is much better than the corresponding grep command, but the speed improvement is also a nice bonus.<p>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.

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 <i>SO</i> much faster than grep that the much small speed differences between them doesn&#x27;t provide much of a basis for differentiating them.<p>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&#x27;t have a need to go from less than 1 second to &quot;a bit less than less than 1 second&quot;.<p>Speed is not the defining attribute of the &quot;new greps&quot; - they need to be assessed and compared in other ways.

The title needs “(2016)”. This is the original announcement, not new information.

well... it is not faster than qgrep :) even though the way both work - differs greatly, and even though qgrep is based on re2 - the speed comes from the presence of index. but then I wonder why people forget the qgrep option, since with large file stores it makes much more sense to use qgrep AND indices, rather than always go through all the files.<p>this above all true UNLESS you need multi-line matches with UTF8, where ripgrep is not so fast, because it needs to fall back to the other PCRE2 lib

I switched from from ripgrep to ugrep and never looked back. It&#x27;s just as fast, but also comes with fuzzy matching (which is <i>super</i> useful), a TUI (useful for code reviews), and can also search in PDFs, archives, etc.<p>The optional Google search syntax also very convenient.<p><a href="https:&#x2F;&#x2F;ugrep.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;ugrep.com</a>

What are the reasons for grep not being replaced&#x2F;improved? This topic seems a bit old by now.

I searched in portage, and it seems there is another version working also with other documents like PDFs and doc.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;phiresky&#x2F;ripgrep-all">https:&#x2F;&#x2F;github.com&#x2F;phiresky&#x2F;ripgrep-all</a>

Using Ripgrep via Consult [1] in Emacs is bliss. It&#x27;s like the rg+fzf thing that some have made, but all inside Emacs. I use the `consult-ripgrep` command <i>all the time</i>, and sometimes I use it to make project-wide edits too! Workflow is search with `consult-ripgrep` -&gt; export results to buffer -&gt; edit buffer -&gt; commit edits back to files. Details at [2] (includes video of me working it)<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;minad&#x2F;consult#grep-and-find">https:&#x2F;&#x2F;github.com&#x2F;minad&#x2F;consult#grep-and-find</a> [2]: <a href="https:&#x2F;&#x2F;lambdaland.org&#x2F;posts&#x2F;2023-05-31_warp_factor_refactor&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;lambdaland.org&#x2F;posts&#x2F;2023-05-31_warp_factor_refactor...</a>

Grep is already pretty much instant so what does it matter?

One thing I wish ripgrep had is support for AND conditions.

ripgrep is easily one of my most used and most loved tools. I use it directly and also have it set as my grpprg in neovim.

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!

I&#x27;ve been using ripgrep for the last year to quickly search massive database dumps. I compared it with grep and it&#x27;s a game changer.

Semi off-topic, I&#x27;ve coded a ncurses-frontend to navigate and filter grep-like results which might be of interest to some of you: <a href="https:&#x2F;&#x2F;github.com&#x2F;gquere&#x2F;ngp2">https:&#x2F;&#x2F;github.com&#x2F;gquere&#x2F;ngp2</a>

But is any of them using `_mm256_sad_epu8` for small, literal strings?

Would be nice if ripgrep was drop in compatible with grep. I&#x27;d feel like a dick writing a shell script for other people to use and forcing them to install a new grep

I love ripgrep for the speed and the more sane defaults. I use it nearly every day.<p>For those just using it to search through a codebase, don&#x27;t forget -F for string literals.

I love ripgrep, it&#x27;s searched a directory in a half-second for a pattern that took GNU grep literally fifteen minutes.

Feels like it should always be included by default on grep level now.

I&#x27;ve been using ag forever - will check out ripgrep.

I can&#x27;t think of a single time I&#x27;ve used grep where I thought &quot;I wish this was faster&quot;.

git grep cannot even find a simple string in its repo.