[burntsushi]

One counter example:

    $ curl -LO 'https://burntsushi.net/stuff/subtitles2016-sample.en.gz'
    $ gzip -d subtitles2016-sample.en.gz
    $ time rg -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.099
    user    0.063
    sys     0.035
    maxmem  923 MB
    faults  0
    $ time LC_ALL=C grep -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.368
    user    0.285
    sys     0.082
    maxmem  25 MB
    faults  0
    $ time rg -c '^\w{42}$' subtitles2016-sample.en
    1

    real    1.195
    user    1.162
    sys     0.031
    maxmem  928 MB
    faults  0
    $ time LC_ALL=en_US.UTF-8 grep -c -E '^\w{42}$' subtitles2016-sample.en
    1

    real    21.261
    user    21.151
    sys     0.088
    maxmem  25 MB
    faults  0

(Yes, ripgrep is matching a Unicode-aware `\w` above, which is why I turned on GNU grep's locale feature. To make it apples-to-apples.)

Now to be fair, you did say "usually." But actually, sometimes, even when functional parity[1] has been achieved (and then some), perf can still be wildly improved.

[1]: ripgrep is not compatible with GNU grep, but there shouldn't be much you can do with grep that you can't do with ripgrep. The main thing would be stuff related to the marriage of locales and regexes, e.g., ripgrep can't do `echo 'pokémon' | LC_ALL=en_US.UTF-8 grep 'pok[[=e=]]mon'`. Conversely, there's oodles that ripgrep can do that GNU grep can't. For example, transparently searching UTF-16. POSIX forbids such wildly popular use cases (e.g., on Windows).

[gibibit]

I've been using ripgrep for years now and I'm still blown away by its performance.

In the blink of an eye to search a couple of gigabytes.

I just checked and did a full search across 100 gigabytes of files in only 21 seconds.

The software is fantastic, and moreover it goes to show what our modern hardware is capable of. In these days of unbelievable software waste and bloat, stuff like ripgrep, dua, and fd reminds me there is hope for a better world.

[burntsushi]

w00t!

[hu3]

I don't think rg speed can be attributed to Rust.

ripgrep gains comes from a ton of brilliant optimizations and strategies done by it's author. They wrote articles about such tricks.

[burntsushi]

> I don't think rg speed can be attributed to Rust.

I didn't say it was, and this isn't even remotely close to my point. The comment I was replying to wasn't even talking about Rust versus C. Just new tools versus old tools.

> ripgrep gains comes from a ton of brilliant optimizations and strategies done by it's author. They wrote articles about such tricks.

I know. I'm its author!

[hu3]

oh hi burntsushi! Good thing I applauded your skills to... yourself, without realizing. haha

I was replying to this:

> Is performance a frequent rationale for rewriting C applications in Rust?

But I now realize your message was much more specific so I stand corrected with regards to context. Your point was indeed different.

[burntsushi]

:-) <3