3 ms·
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 functional
by eej71 2y ago
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.
- burntsushi 2y agoOne 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).
- hu3 2y agoI 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 2y ago> 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 2y agooh 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 2y ago:-) <3
- gibibit 2y agoI'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 2y agow00t!
- nine_k 2y agoNot 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.