I think that's only generally true for the period of time where the new tool has yet to achieve full functional parity with what it replaced. As that functionality gap is closed, the performance increase usually declines too.

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).

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.

w00t!

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.

> 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!

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.

:-) <3

Not necessarily so. Sometimes a better architecture and addressing long-standing technical debt give large permanent gains. Compare yarn vs npm, or even quicksort vs bubble sort.

It's also easier to do things in parallel in rust that might otherwise not have been considered in a C version.

And using more efficient algorithms or data structures that are painful and/or difficult to use in C.

Is that because of the Rayon lib?

It can be, but just plain multi-threading in rust is a lot easier to work with (correctly) than it is in C - just using stdlib and builtin features of rust.