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

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/92cc5f6dc2ff98d098017da71943fc2a6a327e98/src/main.rs#L41 https://github.com/alexpasmantier/grip-grab/blob/92cc5f6dc2f...