4 ms·

ripgrep is noticeably faster than ag. I'm not sure what features you mention that ripgrep is missing, but I've been plenty happy with it for basic grepping arou

ripgrep is noticeably faster than ag. I'm not sure what features you mention that ripgrep is missing, but I've been plenty happy with it for basic grepping around. I'm sure it's also partly because BurntSushi, the author of ripgrep, is reasonably active here. Some fun benchmarks, and a fair description of how text search works, can be found in this 2016 post https://blog.burntsushi.net/ripgrep/ https://blog.burntsushi.net/ripgrep/

chx 5y ago
> ripgrep is noticeably faster than ag. Since both are instant on every codebase I care about, not so sure about that. These tools were always chiefly I/O bound , SSDs have torn that down especially now. But for features: there's no lookaround in the regex.
- aidenn0 5y ago
  These tools are I/o bound, but not disk bound. I often perform multiple searches in a row, and all but the first will hit the disk cache.
- burntsushi 5y ago
  They are only I/O bound when searching data that isn't in cache. It's often the case that you're searching, for example, a repository of code repeatedly. > Since both are instant on every codebase I care about, not so sure about that. It is very possible that there is no performance difference between ripgrep and ag for your use cases, but that does not mean there isn't a performance difference between ripgrep and ag. For example, in my checkout of the chromium repository: $ time rg -c Openbox testing/xvfb.py:2 tools/metrics/histograms/enums.xml:1 ui/base/x/x11_util.cc:1 real 0.448 user 2.593 sys 2.490 maxmem 77 MB faults 0 $ time ag -c Openbox ui/base/x/x11_util.cc:1 tools/metrics/histograms/enums.xml:1 testing/xvfb.py:2 real 2.302 user 2.996 sys 10.462 maxmem 15 MB faults 0 > But for features: there's no lookaround in the regex. That's not true and hasn't been true for a long time. ripgrep supports PCRE2 with the -P/--pcre2 flag. You can even put `--engine auto` in an alias or ripgreprc file and have ripgrep automatically select the regex engine based on whether you're using "fancy" features or not. In general, I also claim that ripgrep has far fewer bugs than ag. ag doesn't really get gitignore support correct, although if you only have simple gitignores, its support might be good enough.

chx 5y ago

> ripgrep is noticeably faster than ag. Since both are instant on every codebase I care about, not so sure about that. These tools were always chiefly I/O bound , SSDs have torn that down especially now. But for features: there's no lookaround in the regex.

aidenn0 5y ago
These tools are I/o bound, but not disk bound. I often perform multiple searches in a row, and all but the first will hit the disk cache.
burntsushi 5y ago
They are only I/O bound when searching data that isn't in cache. It's often the case that you're searching, for example, a repository of code repeatedly. > Since both are instant on every codebase I care about, not so sure about that. It is very possible that there is no performance difference between ripgrep and ag for your use cases, but that does not mean there isn't a performance difference between ripgrep and ag. For example, in my checkout of the chromium repository: $ time rg -c Openbox testing/xvfb.py:2 tools/metrics/histograms/enums.xml:1 ui/base/x/x11_util.cc:1 real 0.448 user 2.593 sys 2.490 maxmem 77 MB faults 0 $ time ag -c Openbox ui/base/x/x11_util.cc:1 tools/metrics/histograms/enums.xml:1 testing/xvfb.py:2 real 2.302 user 2.996 sys 10.462 maxmem 15 MB faults 0 > But for features: there's no lookaround in the regex. That's not true and hasn't been true for a long time. ripgrep supports PCRE2 with the -P/--pcre2 flag. You can even put `--engine auto` in an alias or ripgreprc file and have ripgrep automatically select the regex engine based on whether you're using "fancy" features or not. In general, I also claim that ripgrep has far fewer bugs than ag. ag doesn't really get gitignore support correct, although if you only have simple gitignores, its support might be good enough.