3 ms·

Which is a prototype to the small C utils that solve the problem better, and bash again

by elitepleb 6y ago

drran 6y ago
Small Rust utils are better than C equivalents. Ripgrep is lot faster than grep, despite slower regex engine.
- kortex 6y ago
  I look forward to the slow but steady reinvention of various coreutils in Rust or Go. Rg-ripgrep is better than grep. Fd-find is better than find. Exa is better than ls/tree. Fzf has no equivalent. I'm still looking for a ping that lets me timeout less than 1 second. There are so many assumptions baked in to the early tools that a complete rewrite just bypasses.
- GoblinSlayer 6y ago
  As far as I see, ripgrep isn't small - a multimegabyte heavily compressed package.
  - drran 6y ago
    $ ldd /usr/bin/grep linux-vdso.so.1 (0x00007ffed59ab000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f387c8cf000) libc.so.6 => /lib64/libc.so.6 (0x00007f387c705000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f387c6e3000) /lib64/ld-linux-x86-64.so.2 (0x00007f387c9aa000) $ du -ch /usr/bin/grep `readlink -f /lib64/libpcre.so.1` `readlink -f /lib64/libc.so.6` `readlink -f /lib64/libpthread.so.0` 168K /usr/bin/grep 484K /usr/lib64/libpcre.so.1.2.12 3.1M /usr/lib64/libc-2.31.so 312K /usr/lib64/libpthread-2.31.so 4.0M total
    - GoblinSlayer 6y ago
      I mean https://github.com/BurntSushi/ripgrep/releases/download/12.1.1/ripgrep_12.1.1_amd64.deb https://github.com/BurntSushi/ripgrep/releases/download/12.1... - /usr/bin/rg 5mb executable. And I think it was something about 20mb in first release.
      - burntsushi 6y ago
        Only because I didn't bother to strip the binary. The binary you're linking to is statically linked, which includes PCRE2 and Rust's regex engine, among other things. The GP's point is that if you look at all of grep's pieces, it comes in at a similar size. Overall, I don't even know what the point of this kind of questioning even is.
- burntsushi 6y ago
  What makes you say ripgrep has a slower regex engine?
  - drran 6y ago
    Compare performance of Rust #7 (PCRE2) vs Rust #6 (regex) at benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - burntsushi 6y ago
      That's a single benchmark. Before regex-redux was regex-dna, and Rust's regex engine was faster than PCRE2 on that benchmark. So how does that change your conclusion? The regex crate has many more benchmarks: https://github.com/rust-lang/regex/blob/master/bench/log/07/pcre2 https://github.com/rust-lang/regex/blob/master/bench/log/07/... and https://github.com/rust-lang/regex/blob/master/bench/log/07/rust https://github.com/rust-lang/regex/blob/master/bench/log/07/... for example. And then there are things like this which can impact the performance of real world use cases: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcre2-slow https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcr... Please don't draw sweeping conclusions about the comparative performance of regex engines from a single benchmark.

Which is a prototype to the small C utils that solve the problem better, and bash again

drran 6y ago

Small Rust utils are better than C equivalents. Ripgrep is lot faster than grep, despite slower regex engine.

kortex 6y ago
I look forward to the slow but steady reinvention of various coreutils in Rust or Go. Rg-ripgrep is better than grep. Fd-find is better than find. Exa is better than ls/tree. Fzf has no equivalent. I'm still looking for a ping that lets me timeout less than 1 second. There are so many assumptions baked in to the early tools that a complete rewrite just bypasses.
GoblinSlayer 6y ago
As far as I see, ripgrep isn't small - a multimegabyte heavily compressed package.
- drran 6y ago
  $ ldd /usr/bin/grep linux-vdso.so.1 (0x00007ffed59ab000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f387c8cf000) libc.so.6 => /lib64/libc.so.6 (0x00007f387c705000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f387c6e3000) /lib64/ld-linux-x86-64.so.2 (0x00007f387c9aa000) $ du -ch /usr/bin/grep `readlink -f /lib64/libpcre.so.1` `readlink -f /lib64/libc.so.6` `readlink -f /lib64/libpthread.so.0` 168K /usr/bin/grep 484K /usr/lib64/libpcre.so.1.2.12 3.1M /usr/lib64/libc-2.31.so 312K /usr/lib64/libpthread-2.31.so 4.0M total
  - GoblinSlayer 6y ago
    I mean https://github.com/BurntSushi/ripgrep/releases/download/12.1.1/ripgrep_12.1.1_amd64.deb https://github.com/BurntSushi/ripgrep/releases/download/12.1... - /usr/bin/rg 5mb executable. And I think it was something about 20mb in first release.
    - burntsushi 6y ago
      Only because I didn't bother to strip the binary. The binary you're linking to is statically linked, which includes PCRE2 and Rust's regex engine, among other things. The GP's point is that if you look at all of grep's pieces, it comes in at a similar size. Overall, I don't even know what the point of this kind of questioning even is.
burntsushi 6y ago
What makes you say ripgrep has a slower regex engine?
- drran 6y ago
  Compare performance of Rust #7 (PCRE2) vs Rust #6 (regex) at benchmarks game: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - burntsushi 6y ago
    That's a single benchmark. Before regex-redux was regex-dna, and Rust's regex engine was faster than PCRE2 on that benchmark. So how does that change your conclusion? The regex crate has many more benchmarks: https://github.com/rust-lang/regex/blob/master/bench/log/07/pcre2 https://github.com/rust-lang/regex/blob/master/bench/log/07/... and https://github.com/rust-lang/regex/blob/master/bench/log/07/rust https://github.com/rust-lang/regex/blob/master/bench/log/07/... for example. And then there are things like this which can impact the performance of real world use cases: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcre2-slow https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pcr... Please don't draw sweeping conclusions about the comparative performance of regex engines from a single benchmark.