Feature comparison of ack, ag, git-grep, GNU grep and ripgrep

I added smartcase in ack because I used it constantly in vim. I don't normally want to have to remember if the function I'm searching for is "format_ISBN" or "format_isbn", for example. Some languages (PHP) aren't always case-sensitive, so you need to search both. I'd rather use a "-I" in the few cases where I don't want case-sensitive, than having to remember to add "-i" in the 99% of the cases where I don't.

Well said. :-)

I've added a link to your feature comparison table to my REAMDE[1]. Thanks again for putting it together!

[1] - https://github.com/BurntSushi/ripgrep#feature-comparison

The one thing I wish more of these comparison tables had was licensing info, so for those like me who are curious:

1. GNU grep - GPLv3+

2. ack - Artistic License v2.0

3. ag (aka silver searcher) - Apache License 2.0

4. git-grep - GPlv2+/LGPLv2.1+

5. rg - MIT license

So with maybe the exception of rg, all are gpl compatible, that's great news.

Neither. pt is part of the benchmark suite I published when I introduced ripgrep[1]. TL;DR - It's fast for simple literal searches, but that's it.

[1] - http://blog.burntsushi.net/ripgrep/

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