4 ms·

If you use and like `ag`, I suggest taking a look at ripgrep (`rg`). It seems to be by far the fastest out of three (`ack`, `ag`, `rg`). And it has a pretty int

If you use and like `ag`, I suggest taking a look at ripgrep (`rg`). It seems to be by far the fastest out of three (`ack`, `ag`, `rg`). And it has a pretty interesting codebase (written in Rust).

Myrmornis 8y ago
If you're working in a git repository then IMO the most appropriate search tool is simply `git grep`. I don't think there's any reason to use ripgrep, ag, ack etc in that situation. (Personally, if I'm working with text files, then I'm nearly always in a git repo.)
- burntsushi 8y ago
  (author of ripgrep here) Well at least one reason is because ripgrep is faster. On simple literal queries they'll have comparable speed, but beyond that, `git grep` is _a lot_ slower. Here's an example on a checkout of the Linux kernel: $ time rg '\w+_PM_RESUME' | wc -l 8 real 0.127 user 0.689 sys 0.589 maxmem 19 MB faults 0 $ time LC_ALL=C git grep -E '\w+_PM_RESUME' | wc -l 8 real 4.607 user 28.059 sys 0.442 maxmem 63 MB faults 0 $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_PM_RESUME' | wc -l 8 real 21.651 user 2:09.54 sys 0.413 maxmem 64 MB faults 0 ripgrep supports Unicode by default, so it's actually comparable to the LC_ALL=en_US.UTF-8 variant. There are other reasons. It is nice to use a single tool for searching in all circumstances. ripgrep can fit that role. Maybe you don't know, but ripgrep respects your .gitignore file.
  - Myrmornis 8y ago
    Thanks! I knew ripgrep was praised in particular for its performance but I didn't know the difference was that large. The repo I usually work in has 8.7M lines of code and I had been finding `git grep` performance very adequate (I use it in combination with the Emacs helm library where it forms part of an incremental search UI, and hence gets called multiple times in quick succession in response to changing search input.) It looks like it will be fun to try swapping in ripgrep as the helm search backend; I'll try it.

If you use and like `ag`, I suggest taking a look at ripgrep (`rg`). It seems to be by far the fastest out of three (`ack`, `ag`, `rg`). And it has a pretty interesting codebase (written in Rust).

Myrmornis 8y ago

If you're working in a git repository then IMO the most appropriate search tool is simply `git grep`. I don't think there's any reason to use ripgrep, ag, ack etc in that situation. (Personally, if I'm working with text files, then I'm nearly always in a git repo.)

burntsushi 8y ago
(author of ripgrep here) Well at least one reason is because ripgrep is faster. On simple literal queries they'll have comparable speed, but beyond that, `git grep` is _a lot_ slower. Here's an example on a checkout of the Linux kernel: $ time rg '\w+_PM_RESUME' | wc -l 8 real 0.127 user 0.689 sys 0.589 maxmem 19 MB faults 0 $ time LC_ALL=C git grep -E '\w+_PM_RESUME' | wc -l 8 real 4.607 user 28.059 sys 0.442 maxmem 63 MB faults 0 $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_PM_RESUME' | wc -l 8 real 21.651 user 2:09.54 sys 0.413 maxmem 64 MB faults 0 ripgrep supports Unicode by default, so it's actually comparable to the LC_ALL=en_US.UTF-8 variant. There are other reasons. It is nice to use a single tool for searching in all circumstances. ripgrep can fit that role. Maybe you don't know, but ripgrep respects your .gitignore file.
- Myrmornis 8y ago
  Thanks! I knew ripgrep was praised in particular for its performance but I didn't know the difference was that large. The repo I usually work in has 8.7M lines of code and I had been finding `git grep` performance very adequate (I use it in combination with the Emacs helm library where it forms part of an incremental search UI, and hence gets called multiple times in quick succession in response to changing search input.) It looks like it will be fun to try swapping in ripgrep as the helm search backend; I'll try it.