7 ms·

Show HN: A somewhat faster, more lightweight, ripgrep-inspired alternative

athorax 2y ago
I appreciate including the caveat about this being circumstantially faster, but do you have the benchmarks for the usage cases this performs better than rip-grep?
- alexpasmantier 2y ago
  Hi Thanks for your comment. I uploaded a couple of tests using `hyperfine` to show cases where it might be faster. Will put in more work to do a proper benchmarking session in the days to come.
  - thealistra 2y ago
    Would be good to also do plain text benchmarks, not simple regexes. As I assume this might be the best optimized case
    - alexpasmantier 2y ago
      Done
johnisgood 2y ago
Benchmarks? In what cases is it more performant?
- alexpasmantier 2y ago
  Hi Thanks for your comment. I uploaded a couple of tests using `hyperfine` to show cases where it might be faster. Will put in more work to do a proper benchmarking session in the days to come.
  - johnisgood 2y ago
    Thank you for having added those! What makes it circumstantially more performant, by the way? Off-topic, but consider changing "circumstancially" to "circumstantially" in the README; the latter is the correct term.
    - alexpasmantier 2y ago
      > What makes it circumstantially more performant, by the way? The thread above might help provide the start of an answer. > Off-topic, but consider changing "circumstancially" to "circumstantially" in the README; the latter is the correct term. Done, thanks for spotting the typo.
      - johnisgood 2y ago
        Oh okay, thank you, and you're welcome. :)
burntsushi 2y ago
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...
yoavm 2y ago
The video on the readme doesn't work here on Firefox, Linux. I suspect it's because it's a mov file.
- alexpasmantier 2y ago
  Thanks for the feedback, will update the video!
- alexpasmantier 2y ago
  Changed to mp4, should work now.
VeejayRampay 2y ago
those rust utils are always so fast, it's insane i find that they're also often associated with higher quality READMEs for some reason...
ericyd 2y ago
I understand from other comments that this was started as a learning project, but I gotta say I can't imagine a case where ripgrep wouldn't be fast enough for my use case. Maybe I'm not enough of a power user. Totally fine to have multiple players in the pattern matching CLI space of course, but performance alone would not convince me to switch

I appreciate including the caveat about this being circumstantially faster, but do you have the benchmarks for the usage cases this performs better than rip-grep?

alexpasmantier 2y ago
Hi Thanks for your comment. I uploaded a couple of tests using `hyperfine` to show cases where it might be faster. Will put in more work to do a proper benchmarking session in the days to come.
- thealistra 2y ago
  Would be good to also do plain text benchmarks, not simple regexes. As I assume this might be the best optimized case
  - alexpasmantier 2y ago
    Done

johnisgood 2y ago

Benchmarks? In what cases is it more performant?

alexpasmantier 2y ago
Hi Thanks for your comment. I uploaded a couple of tests using `hyperfine` to show cases where it might be faster. Will put in more work to do a proper benchmarking session in the days to come.
- johnisgood 2y ago
  Thank you for having added those! What makes it circumstantially more performant, by the way? Off-topic, but consider changing "circumstancially" to "circumstantially" in the README; the latter is the correct term.
  - alexpasmantier 2y ago
    > What makes it circumstantially more performant, by the way? The thread above might help provide the start of an answer. > Off-topic, but consider changing "circumstancially" to "circumstantially" in the README; the latter is the correct term. Done, thanks for spotting the typo.
    - johnisgood 2y ago
      Oh okay, thank you, and you're welcome. :)

burntsushi 2y ago

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...

yoavm 2y ago

The video on the readme doesn't work here on Firefox, Linux. I suspect it's because it's a mov file.

alexpasmantier 2y ago
Thanks for the feedback, will update the video!
alexpasmantier 2y ago
Changed to mp4, should work now.

VeejayRampay 2y ago

those rust utils are always so fast, it's insane i find that they're also often associated with higher quality READMEs for some reason...

ericyd 2y ago

I understand from other comments that this was started as a learning project, but I gotta say I can't imagine a case where ripgrep wouldn't be fast enough for my use case. Maybe I'm not enough of a power user. Totally fine to have multiple players in the pattern matching CLI space of course, but performance alone would not convince me to switch