Live data from Hacker News

Ripgrep 15.0

github.com

61–70 of 119 posts

Re: Ripgrep 15.0

#61

Earlier quoted context omitted.

ripgrep is a lot faster (which you might only notice on larger haystacks), has many fewer bugs and is maintained.

ag is plenty fast (gigabytes in a fraction of a second) for me - I'd switch in a heartbeat if that wasn't so. Any bugs, hm, I guess I just haven't run into them. Thanks for the reply though! I realize who replied here ;)

Look at ag's issue tracker. There are some very critical bugs. You might be impacted by them and not even know it.

As for perf, it's not hard to witness a 10x improvement that you'll actually feel. On my checkout of the Linux kernel:

    $ (time rg -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l

    real    0.114
    user    0.547
    sys     0.543
    maxmem  29 MB
    faults  0
    444

    $ (time ag -wi '\w+(PM_RESUME|LINK_REQ)') | wc -l

    real    0.949
    user    6.618
    sys     0.805
    maxmem  65 MB
    faults  0
    444
Or even basic queries can have a pretty big difference. In my checkout of the Chromium repository:

    $ (time rg Openbox) | wc -l

    real    0.296
    user    1.349
    sys     1.950
    maxmem  71 MB
    faults  0
    11

    $ (time ag Openbox) | wc -l

    real    1.528
    user    1.849
    sys     8.285
    maxmem  29 MB
    faults  0
    11
Or even more basic. You might search a file that is "too big" for ag:

    $ time ag '^\w{42}$' full.txt
    ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.

Re: Ripgrep 15.0

#62
I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?

Re: Ripgrep 15.0

#63
post #62

I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?

Fewer bugs?

And perf depends on your haystack size. If you have lots of data to search, it's not hard to witness a 10x difference: https://news.ycombinator.com/item?id=45629904

As for features that ripgrep has that ag doesn't:

* Much better Unicode support. (ag's is virtually non-existent.)

* Pluggable preprocessors with --pre.

* Jujutsu support.

* ripgrep can automatically search UTF-16 data.

* ripgrep has PCRE2 support. ag only has PCRE1 (which was EOL'd years ago).

* ripgrep has a `-r/--replace` flag that lets you manipulate the output. I use it a lot instead of `sed` or `awk` (for basic cases) these days.

* ripgrep is maintained.

* ripgrep has multiline search that seemingly works much better.

* ripgrep can search files bigger than 2GB. ag seemingly can't.

* ag has lots of whacky bugs.

e.g.,

    $ ag -c '\w{8,} Sherlock Holmes' sixteenth.txt
    9
    $ rg -c '\w{8,} Sherlock Holmes' sixteenth.txt
    9
    $ cat sixteenth.txt | rg -c '\w{8,} Sherlock Holmes'
    9
    $ cat sixteenth.txt | ag -c '\w{8,} Sherlock Holmes'
    1
    1
    1
    1
    1
    1
    1
    1
    1
Or:

    $ printf 'foo\nbar\n' | ag 'foo\s+bar'
    $ printf 'foo\nbar\n' | rg -U 'foo\s+bar'
    foo
    bar
Or:

    $ ag '\w+ Sherlock Holmes' full.txt
    ERR: Skipping full.txt: pcre_exec() can't handle files larger than 2147483647 bytes.
There's probably more. But that's what comes to mind.

Re: Ripgrep 15.0

#66

For searching file contents, is there a way to start rg with no search string?

What do you mean? You could pass an empty pattern. But that will match everything. Maybe talk about your use case at a higher level.

Thanks for the response. I would like to use fzf with rg to search file contents with a previewer open. However when I first open fzf I don't wish to pass any argument to rg, until I start typing. Something like Telescope live_grep.

Re: Ripgrep 15.0

#67

Earlier quoted context omitted.

What do you mean? You could pass an empty pattern. But that will match everything. Maybe talk about your use case at a higher level.

Thanks for the response. I would like to use fzf with rg to search file contents with a previewer open. However when I first open fzf I don't wish to pass any argument to rg, until I start typing. Something like Telescope live_grep.

That's more a question for fzf than for ripgrep. ripgrep doesn't have any interactive mode. You give it arguments and it runs. That's it. ripgrep doesn't have any mode where it waits for user input (unless it's waiting for stdin).

Re: Ripgrep 15.0

#68
post #57
post #41

This week I wrote a small bash function that run ripgrep only on the files that are tracked by git: rgg() { readarray -d '' -t FILES It speeds up a lot on directories with many binary files and committed dot files. To search the dot files, -uu is needed, but that also tells ripgrep to search the binary files. On repositories with hundreds of files, the git ls-files overhead a bit large.

Is this faster than `git grep`?

No, amazingly (to me) on the repo in question, `git grep` is twice as fast as `ripgrep -w.` or the custom `rgg` function.

All are less than 100ms, so fast enough.

Re: Ripgrep 15.0

#69
post #49

Earlier quoted context omitted.

The point is to search hidden files that are tracked by git. An example is CI scripts which are stored in places like .woodpecker, .forgejo, .gitlab-ci-yml.

One thing you might consider to make this more streamlined for you is this: $ printf '!.woodpecker\n!.forgejo\n!.gitlab-ci-yml\n' > .rgignore Or whatever you need to whitelist specific hidden directories/files. For example, ripgrep has `!/.github/` in its `.ignore` file at the root of the repository[1]. By adding the `!`, these files get whitelisted even though they are hidden. Then `rg` with no extra arguments will…

That's a great suggestion for .rgignore and ~/.rgignore.

Re: Ripgrep 15.0

#70

Earlier quoted context omitted.

Thanks for the response. I would like to use fzf with rg to search file contents with a previewer open. However when I first open fzf I don't wish to pass any argument to rg, until I start typing. Something like Telescope live_grep.

That's more a question for fzf than for ripgrep. ripgrep doesn't have any interactive mode. You give it arguments and it runs. That's it. ripgrep doesn't have any mode where it waits for user input (unless it's waiting for stdin).

You could have incorporated some snark or something, but no, you're always the most helpful you can be. You're very inspirational - thank you!

(Also like thanks for ripgrep I guess?)

Post reply on HN