It's a simple break down of communication. I try to be upfront about this, but no matter how hard I try or how many times I try to clarify it, I can't stop the spread of inaccurate claims. (And my goodness, this entire HN thread has numerous inaccuracies just with GNU grep alone.)

On equivalent tasks, ripgrep is not orders of magnitude faster than GNU grep, outside of pathological cases that involve Unicode support. (I can provide evidence for that if you like.)

For example, in my checkout of the Linux kernel, here's a recursive grep that searches everything:

    $ time LC_ALL=C grep -ar PM_RESUME | wc -l
    17

    real    1.176
    user    0.758
    sys     0.407
    maxmem  7 MB
    faults  0

Now compare that with ripgrep, with a command that uses the same amount of parallelism and searches the same amount of data:

    $ time rg -j1 -uuu PM_RESUME | wc -l
    17

    real    0.581
    user    0.187
    sys     0.384
    maxmem  7 MB
    faults  0

Which is 2x faster, but not "order of magnitude." Now compare it with how long ripgrep takes using the default command:

    $ time rg PM_RESUME | wc -l
    17

    real    0.125
    user    0.646
    sys     0.654
    maxmem  19 MB
    faults  0

At 10x faster, this is where you start to get to "order of magnitude" faster claims. But for someone who cares about precise claims with respect to performance, this is uninteresting because ripgrep is 1) using parallelism and 2) skipping some files due to `.gitignore` and other such rules.

You can imagine that if your directory has a lot of large binary files, or if you're searching in a directory with high latency (a network mount), then you might see even bigger differences from ripgrep without generally seeing a difference in search results because ripgrep tends to skip things you don't care about anyway.

In summary, there is an impedance mismatch when talking about performance because most people don't have a good working mental model of how these tools work internally. Many people report on their own perceived performance improvements and compare that directly to how they used to use grep. They aren't wrong in a certain light, because ultimately, the user experience is what matters. But of course, they are wrong in another light if you're interpreting it as a precise technical claim about the performance characteristics of a program.