Is performance a frequent rationale for rewriting C applications in Rust?
But that's at least partially a maintainability argument, not just a performance one. Rust can make achieving higher levels of performance easier and less risky than doing so in C or C++ would have, but you do still have to work for it a little, it's not going to be magically faster.
$ 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
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).
ripgrep gains comes from a ton of brilliant optimizations and strategies done by it's author. They wrote articles about such tricks.
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!
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.
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.