3 ms·

The benchmark suite can be run by anyone: https://github.com/BurntSushi/ripgrep/blob/master/benchsuite/benchsuite https://github.com/BurntSushi/ripgrep/blob/mas

The benchmark suite can be run by anyone: https://github.com/BurntSushi/ripgrep/blob/master/benchsuite/benchsuite https://github.com/BurntSushi/ripgrep/blob/master/benchsuite... I re-ran them :-) https://github.com/BurntSushi/ripgrep/tree/master/benchsuite/runs/2018-01-08-archlinux-cheetah https://github.com/BurntSushi/ripgrep/tree/master/benchsuite... TL;DR ripgrep has gotten faster in important areas since the initial set of benchmarks (the proper comparison there would be https://github.com/BurntSushi/ripgrep/tree/master/benchsuite/runs/2016-09-22-archlinux-cheetah https://github.com/BurntSushi/ripgrep/tree/master/benchsuite...). The key reasons why are because it grew a parallel directory traverser, and its line counting got vectorized courtesy of the bytecount[1] crate. ucg has gotten a little faster in some cases, but the general conclusion of "ripgrep is the fastest" is still correct. [1] - https://github.com/llogiq/bytecount https://github.com/llogiq/bytecount

bradknowles 9y ago
Thank you for re-running them. You saved me the trouble. ;) I would be curious to see ack get into the test suite, however. Even if it is much slower, I'd like to see the results. And I'd be very curious to hear your reasoning for the different results in the subtitles_ru test cases -- why is rg returning radically different numbers of lines as compared to the other tools? Thanks!
- burntsushi 9y ago
  > I would be curious to see ack get into the test suite, however. Even if it is much slower, I'd like to see the results. You'll need to add it to the benchsuite script (which should be very easy to do, just peruse the source to see other examples), but for me, ack is too slow to benchmark this way. In theory, I'd be fine adding it to the same benchmarks as pt/sift are in, since they are also generally too slow to benchmark, but are at least fast enough in some of them to tolerate it. But ack has different characteristics. While pt/sift have a very high ceiling (like ack), they also have a very low floor in some cases. ack on the other hand has a reasonably high floor compared to the others, even in the simplest searches. This makes all benchmarks on ack take a long time. I did a couple ad hoc benchmarks on the same machine: ripgrep ack linux_alternates 0.113s 9.750s linux_alternates_casei 0.133s 19.955s linux_literal 0.103s 7.220s linux_literal_casei 0.122s 8.025s linux_no_literal 0.356s 18.881s linux_re_literal_suffix 0.104s 6.778s linux_unicode_greek 0.194s 8.537s (ack reports no results) linux_unicode_word 0.111s 7.299s linux_word 0.108s 6.763s subtitles_en_alternate 0.247s 9.829s subtitles_en_alternate_casei 0.247s 43.091s subtitles_ru_alternate 0.978s 28.134s subtitles_ru_alternate_casei 0.978s 107.314s (ack reports incorrect) subtitles_ru_surrounding_words 0.245s 6.633s (ack reports no results) The subtitles benchmarks are perhaps unfair because I think ack is more focused on directory tree search where as ripgrep claims to be good at both. I included a few anyway to show the difference though. In general, the benchmark just isn't that interesting, and it makes the benchmark run take a lot longer than it would otherwise (because each command is executed several times). > And I'd be very curious to hear your reasoning for the different results in the subtitles_ru test cases -- why is rg returning radically different numbers of lines as compared to the other tools? Because ripgrep correctly supports Unicode, and does it by default because it can generally handle all Unicode features without a corresponding performance loss. GNU grep handles Unicode in general as well (assuming your system's locale settings are up to snuff), but it can pay a huge price for it some cases, although admittedly, I'd consider such cases to be somewhat infrequent in common usage. It's explained in my blog post: http://blog.burntsushi.net/ripgrep/#single-file-benchmarks http://blog.burntsushi.net/ripgrep/#single-file-benchmarks --- The subtitles_no_literal is particularly interesting, because it shows what happens when you ask GNU grep to do the correct thing. ;-) Note that both ag and ucg have the opportunity to support Unicode correctly, but they don't twiddle the right flags in their use of PCRE (and PCRE2, respectively). AFAIK, neither expose a flag to twiddle these things. From scanning the ack man page, I don't see any option there either, although I'm sure Perl regexes probably have that option too.
  - bradknowles 9y ago
    Awesome! Thanks for all the information! I feel kinda sad that the only thing I can do in response is to go install ripgrep and use that instead of the alternatives. Do you have a Patreon page? Or anything similar?
    - burntsushi 9y ago
      Haha go for it! :-) And no, I don't mix money with my free time side projects. Personal choice. Instead, just donate to a charity. My personal favorites are Rails Girls and Wikipedia. The Internet Archive is another good one!
- petdance 9y ago
  ack will always be slower than ripgrep, but it shouldn't be as slow as it is in burntsushi's tests. In his tests, he's showing run times where ack takes 25x as long to run as ripgrep, and ack shouldn't be NEARLY that slow. We think that there's something weird about his Perl installation that is making it so slow, but we haven't been able to figure it out. Here's the ticket: https://github.com/beyondgrep/ack3/issues/42 https://github.com/beyondgrep/ack3/issues/42 If you have any insight, we'd love to have it. We've been stumped, as you'll see if you read through the issue history.
  - burntsushi 9y ago
    I will dig back into this and see if I can figure it out. If you look at the recent commit history for ripgrep, you'll see I updated the timings for ack on my benchmark in my README. I have no explanation for it, but ack isn't as slow as it was when I went through this before. Anyway, my Perl installation is the standard one on Archlinux. I will try on other systems.

bradknowles 9y ago

Thank you for re-running them. You saved me the trouble. ;) I would be curious to see ack get into the test suite, however. Even if it is much slower, I'd like to see the results. And I'd be very curious to hear your reasoning for the different results in the subtitles_ru test cases -- why is rg returning radically different numbers of lines as compared to the other tools? Thanks!

burntsushi 9y ago
> I would be curious to see ack get into the test suite, however. Even if it is much slower, I'd like to see the results. You'll need to add it to the benchsuite script (which should be very easy to do, just peruse the source to see other examples), but for me, ack is too slow to benchmark this way. In theory, I'd be fine adding it to the same benchmarks as pt/sift are in, since they are also generally too slow to benchmark, but are at least fast enough in some of them to tolerate it. But ack has different characteristics. While pt/sift have a very high ceiling (like ack), they also have a very low floor in some cases. ack on the other hand has a reasonably high floor compared to the others, even in the simplest searches. This makes all benchmarks on ack take a long time. I did a couple ad hoc benchmarks on the same machine: ripgrep ack linux_alternates 0.113s 9.750s linux_alternates_casei 0.133s 19.955s linux_literal 0.103s 7.220s linux_literal_casei 0.122s 8.025s linux_no_literal 0.356s 18.881s linux_re_literal_suffix 0.104s 6.778s linux_unicode_greek 0.194s 8.537s (ack reports no results) linux_unicode_word 0.111s 7.299s linux_word 0.108s 6.763s subtitles_en_alternate 0.247s 9.829s subtitles_en_alternate_casei 0.247s 43.091s subtitles_ru_alternate 0.978s 28.134s subtitles_ru_alternate_casei 0.978s 107.314s (ack reports incorrect) subtitles_ru_surrounding_words 0.245s 6.633s (ack reports no results) The subtitles benchmarks are perhaps unfair because I think ack is more focused on directory tree search where as ripgrep claims to be good at both. I included a few anyway to show the difference though. In general, the benchmark just isn't that interesting, and it makes the benchmark run take a lot longer than it would otherwise (because each command is executed several times). > And I'd be very curious to hear your reasoning for the different results in the subtitles_ru test cases -- why is rg returning radically different numbers of lines as compared to the other tools? Because ripgrep correctly supports Unicode, and does it by default because it can generally handle all Unicode features without a corresponding performance loss. GNU grep handles Unicode in general as well (assuming your system's locale settings are up to snuff), but it can pay a huge price for it some cases, although admittedly, I'd consider such cases to be somewhat infrequent in common usage. It's explained in my blog post: http://blog.burntsushi.net/ripgrep/#single-file-benchmarks http://blog.burntsushi.net/ripgrep/#single-file-benchmarks --- The subtitles_no_literal is particularly interesting, because it shows what happens when you ask GNU grep to do the correct thing. ;-) Note that both ag and ucg have the opportunity to support Unicode correctly, but they don't twiddle the right flags in their use of PCRE (and PCRE2, respectively). AFAIK, neither expose a flag to twiddle these things. From scanning the ack man page, I don't see any option there either, although I'm sure Perl regexes probably have that option too.
- bradknowles 9y ago
  Awesome! Thanks for all the information! I feel kinda sad that the only thing I can do in response is to go install ripgrep and use that instead of the alternatives. Do you have a Patreon page? Or anything similar?
  - burntsushi 9y ago
    Haha go for it! :-) And no, I don't mix money with my free time side projects. Personal choice. Instead, just donate to a charity. My personal favorites are Rails Girls and Wikipedia. The Internet Archive is another good one!
petdance 9y ago
ack will always be slower than ripgrep, but it shouldn't be as slow as it is in burntsushi's tests. In his tests, he's showing run times where ack takes 25x as long to run as ripgrep, and ack shouldn't be NEARLY that slow. We think that there's something weird about his Perl installation that is making it so slow, but we haven't been able to figure it out. Here's the ticket: https://github.com/beyondgrep/ack3/issues/42 https://github.com/beyondgrep/ack3/issues/42 If you have any insight, we'd love to have it. We've been stumped, as you'll see if you read through the issue history.
- burntsushi 9y ago
  I will dig back into this and see if I can figure it out. If you look at the recent commit history for ripgrep, you'll see I updated the timings for ack on my benchmark in my README. I have no explanation for it, but ack isn't as slow as it was when I went through this before. Anyway, my Perl installation is the standard one on Archlinux. I will try on other systems.