4 ms·

> You are already using “performance will be looked at later” versions of grep Are you referring to GNU grep? Because if so, this is wildly untrue. GNU grep ha

> You are already using “performance will be looked at later” versions of grep Are you referring to GNU grep? Because if so, this is wildly untrue. GNU grep has been very significantly optimized. There are huge piles of code, including an entire regex engine, in GNU grep specifically for running searches more quickly. Maybe something like busybox's or BSD's grep would satisfy "performance will be looked at later," but certainly not GNU grep. I can't tell which one you're referring to, but a generic "you are already using" seems to at least include GNU grep.

littlestymaar 2y ago
What I mean is not really that grep hasn't been optimized, but that it kind of looks like it is. It's now far from the state of the art from most perspective (in part because of you). And because there exists alternative that in most workloads are much faster than grep without really endangering grep's prominence, it shows that performance isn't really a criteria in its use nowadays (computers are fast). My point as a whole is that as long as the implementation isn't catastrophically slow, then any port is good even if it's slower than GNU's because workloads that both care about max performance, and must be 100% compatible with the original, is small enough.
- burntsushi 2y ago
  I didn't really want to engage with your broader point. I do disagree with it, but only in a measure of degree, and that's hard to debate because it's perspective and opinion oriented. If performance wasn't as important as you seem to imply, it's very unlikely that ripgrep would have gotten popular given that performance (and filtering) are its two more critical features. That is, that's what I hear from users the most: the like ripgrep because it's fast or because it filters or because of both. But on the smaller point, it is just factually untrue that GNU grep falls into the "performance will be looked at later" bucket. That was why I responded. This post is a classic about why GNU grep is fast, demonstrating that GNU grep definitely doesn't look like it wasn't optimized: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug... And then before that, there's this: https://ridiculousfish.com/blog/posts/old-age-and-treachery.html https://ridiculousfish.com/blog/posts/old-age-and-treachery....
  - littlestymaar 2y ago
    > if performance wasn't as important as you seem to imply, it's very unlikely that ripgrep would have gotten popular given that performance (and filtering) are its two more critical features. I'm not saying performance isn't a feature, but if one want performance they shouldn't use grep, and use ripgrep instead. There was a need for a high performance grep replacement, and you filled it perfectly. But now that ripgrep exists, I don't think it makes much sense for a grep perfect clone to seek max performance, since it will definitely fall behind ripgrep no matter how hard they tried (at least because they can't ignore files or restrict the kind of regular expressions they support by default).
    - burntsushi 2y ago
      I don't really share that philosophy personally. But I do think there is a balancing act. There's a big gulf between "not catastrophically slow" and "state of the art." :-)

littlestymaar 2y ago

What I mean is not really that grep hasn't been optimized, but that it kind of looks like it is. It's now far from the state of the art from most perspective (in part because of you). And because there exists alternative that in most workloads are much faster than grep without really endangering grep's prominence, it shows that performance isn't really a criteria in its use nowadays (computers are fast). My point as a whole is that as long as the implementation isn't catastrophically slow, then any port is good even if it's slower than GNU's because workloads that both care about max performance, and must be 100% compatible with the original, is small enough.

burntsushi 2y ago
I didn't really want to engage with your broader point. I do disagree with it, but only in a measure of degree, and that's hard to debate because it's perspective and opinion oriented. If performance wasn't as important as you seem to imply, it's very unlikely that ripgrep would have gotten popular given that performance (and filtering) are its two more critical features. That is, that's what I hear from users the most: the like ripgrep because it's fast or because it filters or because of both. But on the smaller point, it is just factually untrue that GNU grep falls into the "performance will be looked at later" bucket. That was why I responded. This post is a classic about why GNU grep is fast, demonstrating that GNU grep definitely doesn't look like it wasn't optimized: https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html https://lists.freebsd.org/pipermail/freebsd-current/2010-Aug... And then before that, there's this: https://ridiculousfish.com/blog/posts/old-age-and-treachery.html https://ridiculousfish.com/blog/posts/old-age-and-treachery....
- littlestymaar 2y ago
  > if performance wasn't as important as you seem to imply, it's very unlikely that ripgrep would have gotten popular given that performance (and filtering) are its two more critical features. I'm not saying performance isn't a feature, but if one want performance they shouldn't use grep, and use ripgrep instead. There was a need for a high performance grep replacement, and you filled it perfectly. But now that ripgrep exists, I don't think it makes much sense for a grep perfect clone to seek max performance, since it will definitely fall behind ripgrep no matter how hard they tried (at least because they can't ignore files or restrict the kind of regular expressions they support by default).
  - burntsushi 2y ago
    I don't really share that philosophy personally. But I do think there is a balancing act. There's a big gulf between "not catastrophically slow" and "state of the art." :-)