ripgrep author here. I'm not sure I totally get the motivation here to be honest. It is certainly more lightweight in the sense that it has fewer features, but it actually has more dependencies than ripgrep and takes about as long to compile (from scratch) on my system. Also, the flags that it does support are overriding long-held custom that are likely to be confusing to users. For example, -f doesn't read patterns from a file. (ripgrep does this to an extent as well, for example, -I/--no-filename instead of grep's -h/--no-filename to allow `rg -h` to adhere to an even stronger custom: show the help output.)

It's also pretty annoying to share screenshots of benchmarks instead of just showing a simple copyable command with a paste of the results.

I also can't quite reproduce at least the curl benchmark:

    $ hyperfine "rg '[A-Z]+_NOBODY' ." "gg '[A-Z]+_NOBODY'" "grep -rE '[A-Z]+_NOBODY' ."
    Benchmark 1: rg '[A-Z]+_NOBODY' .
      Time (mean ± σ):       9.7 ms ±   0.9 ms    [User: 17.1 ms, System: 16.0 ms]
      Range (min … max):     7.4 ms …  13.1 ms    289 runs

    Benchmark 2: gg '[A-Z]+_NOBODY'
      Time (mean ± σ):      13.3 ms ±   1.1 ms    [User: 19.9 ms, System: 13.2 ms]
      Range (min … max):    10.8 ms …  16.3 ms    211 runs

    Benchmark 3: grep -rE '[A-Z]+_NOBODY' .
      Time (mean ± σ):      40.2 ms ±   3.1 ms    [User: 24.3 ms, System: 15.7 ms]
      Range (min … max):    36.4 ms …  49.3 ms    75 runs

    Summary
      rg '[A-Z]+_NOBODY' . ran
        1.36 ± 0.17 times faster than gg '[A-Z]+_NOBODY'
        4.13 ± 0.50 times faster than grep -rE '[A-Z]+_NOBODY' .

But the times here are so fast that this is likely not the most reliable of benchmarks. Doing it on a bigger repo gives a better sense I think:

    $ git remote -v
    origin  git@github.com:nwjs/chromium.src (fetch)
    origin  git@github.com:nwjs/chromium.src (push)
    $ git rev-parse HEAD
    1e57811fe4583ac92d2f277837718486fbb98252
    $ hyperfine "rg -p Openbox ." "gg Openbox ."
    Benchmark 1: rg -p Openbox .
      Time (mean ± σ):     317.4 ms ±   6.6 ms    [User: 1327.6 ms, System: 2335.4 ms]
      Range (min … max):   308.6 ms … 326.3 ms    10 runs

    Benchmark 2: gg Openbox .
      Time (mean ± σ):     734.5 ms ±  13.0 ms    [User: 1336.3 ms, System: 1567.0 ms]
      Range (min … max):   718.1 ms … 756.1 ms    10 runs

    Summary
      rg -p Openbox . ran
        2.31 ± 0.06 times faster than gg Openbox .

I tried other queries. For example, `gg '\w'`, to get a sense of whether the simpler grep implementation is better at dealing with match overhead. But I get a panic on this line in `gg`[1]. It looks like it's assuming that the `ArrayQueue` it uses is never full?

Even with the failure though, we can look at its perf on a checkout of the Linux kernel:

    $ hyperfine -i "rg '\w' ." "gg '\w' ."
    Benchmark 1: rg '\w' .
      Time (mean ± σ):     266.2 ms ±   6.5 ms    [User: 2168.8 ms, System: 807.6 ms]
      Range (min … max):   254.8 ms … 275.4 ms    11 runs

    Benchmark 2: gg '\w' .
      Time (mean ± σ):      1.043 s ±  0.086 s    [User: 3.569 s, System: 0.260 s]
      Range (min … max):    0.904 s …  1.150 s    10 runs

      Warning: Ignoring non-zero exit code.

    Summary
      rg '\w' . ran
        3.92 ± 0.34 times faster than gg '\w' .

I tried finding other cases where `gg` is meaningfully faster, but I didn't turn anything up.

Now, grip-grab is using the same libraries as ripgrep. So why doesn't it have the same performance profile as ripgrep? That is harder to answer, but it's likely not using the libraries in the best way possible. That's largely my failing, since the libraries are poorly documented, complex and sprawling.

[1]: https://github.com/alexpasmantier/grip-grab/blob/92cc5f6dc2f...