Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.burntsushi.net

Post reply on HN
Print view View original

41–50 of 198 posts

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

#41

Post by porwah »

MrHamdulay wrote: post #22

What's interesting is that ripgrep now also powers VS Code search with a Node.js wrapper. https://www.npmjs.com/package/@vscode/ripgrep

...which is awesome if you can request/install VS Code but not ripgrep.

You can find the rg binary in the VS installation (at least, I can on Windows at my place of employment).

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

#42

Post by burntsushi »

ctenb wrote: post #28
larodi wrote: post #24

Earlier quoted context omitted.

I really doubt git grep can outperform ripgrep in any tests... please provide some proof.

I tested this on a large repo in 2016 when I installed several tools (including rg and ag) to compare speed. I don't have the metrics anymore, but the results were pretty clear then. According to the benchmarks from the OP, git grep is pretty comparable to rg in a large git repo. I guess different benchmarks give slightly different results, but the OP acknowledges that git grep is very fast. Bonus is that it comes pr…

Author of ripgrep here.

It really just depends. The way I like to characterize `git grep` (at present) is that it has sharp performance cliffs. ripgrep has them too, to be sure, but I think it has fewer of them.

If you're just searching for a simple literal, `git grep` is decently fast:

    $ git remote -v
    origin  git@github.com:torvalds/linux (fetch)
    origin  git@github.com:torvalds/linux (push)

    $ git rev-parse HEAD
    f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6

    $ time LC_ALL=en_US.UTF-8 git grep -c -E 'PM_RESUME'
    Documentation/dev-tools/sparse.rst:3
    Documentation/translations/zh_CN/dev-tools/sparse.rst:3
    Documentation/translations/zh_TW/sparse.txt:3
    arch/arm/mach-omap2/omap-secure.h:1
    arch/arm/mach-omap2/pm33xx-core.c:1
    arch/x86/kernel/apm_32.c:1
    drivers/input/mouse/cyapa.h:1
    drivers/mtd/maps/pcmciamtd.c:1
    drivers/net/wireless/intersil/hostap/hostap_cs.c:1
    drivers/net/wwan/t7xx/t7xx_pci.c:15
    drivers/net/wwan/t7xx/t7xx_reg.h:7
    drivers/usb/mtu3/mtu3_hw_regs.h:1
    include/uapi/linux/apm_bios.h:1

    real    0.215
    user    0.421
    sys     1.226
    maxmem  161 MB
    faults  0

    $ time rg -c 'PM_RESUME'
    drivers/mtd/maps/pcmciamtd.c:1
    drivers/net/wwan/t7xx/t7xx_reg.h:7
    drivers/net/wwan/t7xx/t7xx_pci.c:15
    drivers/net/wireless/intersil/hostap/hostap_cs.c:1
    drivers/usb/mtu3/mtu3_hw_regs.h:1
    drivers/input/mouse/cyapa.h:1
    arch/x86/kernel/apm_32.c:1
    Documentation/translations/zh_CN/dev-tools/sparse.rst:3
    Documentation/translations/zh_TW/sparse.txt:3
    Documentation/dev-tools/sparse.rst:3
    arch/arm/mach-omap2/pm33xx-core.c:1
    arch/arm/mach-omap2/omap-secure.h:1
    include/uapi/linux/apm_bios.h:1

    real    0.078
    user    0.259
    sys     0.577
    maxmem  15 MB
    faults  0
But if you switch it up and start adding regex things to your pattern, there can be substantial slowdowns:

    $ time LC_ALL=C git grep -c -E '\w{5,}\s+PM_RESUME'
    Documentation/dev-tools/sparse.rst:1
    Documentation/translations/zh_CN/dev-tools/sparse.rst:1
    Documentation/translations/zh_TW/sparse.txt:1

    real    5.704
    user    55.671
    sys     0.585
    maxmem  207 MB
    faults  0

    $ time LC_ALL=en_US.UTF-8 git grep -c -E '\w{5,}\s+PM_RESUME'
    Documentation/dev-tools/sparse.rst:1
    Documentation/translations/zh_CN/dev-tools/sparse.rst:1
    Documentation/translations/zh_TW/sparse.txt:1

    real    24.529
    user    4:34.42
    sys     0.753
    maxmem  211 MB
    faults  0

    $ time LC_ALL=en_US.UTF-8 git grep -c -P '\w{5,}\s+PM_RESUME'
    Documentation/dev-tools/sparse.rst:1
    Documentation/translations/zh_CN/dev-tools/sparse.rst:1
    Documentation/translations/zh_TW/sparse.txt:1

    real    1.372
    user    16.980
    sys     0.647
    maxmem  211 MB
    faults  1

    $ time rg -c '\w{5,}\s+PM_RESUME'
    Documentation/translations/zh_CN/dev-tools/sparse.rst:1
    Documentation/dev-tools/sparse.rst:1
    Documentation/translations/zh_TW/sparse.txt:1

    real    0.082
    user    0.226
    sys     0.612
    maxmem  18 MB
    faults  0
In the above cases, ripgrep has Unicode enabled. (It's enabled by default irrespective of locale settings. ripgrep doesn't interact with POSIX locales at all.)

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

#43

Post by tambourine_man »

stinos wrote: 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…

Vim is almost broken for me without fzf+rg. Feels like I’m manually grinding coffee instead of using electricity.

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

#45

Post by burntsushi »

masklinn wrote: post #11
zoobab wrote: post #5

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

I don’t think there’s been a point to using `git grep` since ack started parsing gitignore. As far as I’m concerned the use case of `git grep` is to search into non-checked-out trees (by giving it a tree-ish). And it’s not super great at that, because it searches a static tree-ish, so pickaxe filters are generally more useful (though they’re slow). Once again mercurial has/had more useful defaults, `hg grep` searches…

Small clarification: ack did not and does not respect your gitignore files. I just tried it myself, and indeed it doesn't. And this is consistent with the feature chart maintained by the author of ack: https://beyondgrep.com/feature-comparison/

One practical result of this is that it will mean `ack` will be quite slow when searching typical checkouts of Node.js or Rust projects, because it won't automatically ignore the `node_modules` or `target` directories. In both cases, those directories can become enormous.

`ack` will ignore things like `.git` by default though.

I believe `ag` was the first widely used grep-like tool that attempted to respect your .gitignore files automatically. (Besides, of course, `git grep`. But `git grep` behaves a little differently. It only searches what is tracked in the repo, and that may or may not be in sync with the rules in your gitignores.)

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

#46

Post by anonymous_sorry »

mariopt wrote: post #38

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

These benchmarking results are seven years old, so perhaps it has been.

My entirely anecdotal and unscientific impression is that rg and grep perform similarly on Linux (though rg has nicer defaults for searching through source code). The old version of grep that Apple preinstalls on the Mac was slower last time I checked though.

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

#47

Post by asicsp »

capableweb wrote: post #40
mariopt wrote: post #38

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

There are multiple alternatives you can already use as an alternative, like ripgrep. What are you proposing, switching out the command `grep` for another utility? Sounds like that could introduce a ton of breakage, for little value. People who want a faster grep will use a different thing, while people who use grep can continue to use it. Sounds like an ideal situation already.

Another reason would be if you want to follow POSIX standards. For example, `GNU grep` supports `POSIXLY_CORRECT` environment variable.

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

#48

Post by burntsushi »

susam wrote: post #36

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: (add-hook 'xref-backend-functions #'dumb-jump-xref-activate) The Xref key sequences and comma…

Author of ripgrep here.

Looking at your regex---just by inspection, I haven't tried it, so I could be wrong---but I think you can drop the --pcre2 flag. I also think you can drop the second and third \b assertion. You might need the first one though.

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

#49

Post by burntsushi »

mariopt wrote: post #38

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

There's like a whole host of things you could use to explain it. Inertia. Compatibility. Resistance to change. Innovator's dilemma. And so on. (I do not say any of these things pejoratively! All of those things apply to me too.)

With respect to compatibility, see my FAQ on the topic: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

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

#50

Post by burntsushi »

kmarc wrote: post #44
nikbackm wrote: post #32

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

Maybe I'm missing something but I only use it with AND conditions (usually in the form of 'foo 'bar and it only matches lines with foo AND bar both present)

A search for `rg -e foo -e bar` will return lines that match either foo or bar. Some lines may have both, but it isn't required.

The standard way to run "AND" queries is through shell pipelines. That is, `rg foo | rg bar` will only print lines containing both. But composition usually comes with costs. The output reverts to the standard grep format and it doesn't interact nicely with contextual options like -C/--context.

See: https://github.com/BurntSushi/ripgrep/issues/875

Post reply on HN