A similar post popped up a couple weeks ago, and one comment suggested https://github.com/ggreer/the_silver_searcher. I was using ack at the time, but I'm really liking ag as I've found to be quite a bit faster. The one thing I wish it had was being able to restrict searches by file type.
I second this. My friend kept suggesting I switch from Greg to ack. I searched for it and found ag and fell in love with it's speed. That same friend has now switched too.
Thanks, I was looking for this as well. ag --help could probably be reworked a little bit; --include makes more sense than -G / --file-search-regex in my opinion.
for those who are frequently searching paths with a large number of files stored on an SSD or ramdisk/tmpfs, the bottleneck is very much the CPU time.
in these cases ag is noticeably faster (orders of magnitude, in some cases), especially if you're just searching a literal and not with a regex pattern.
the author has done some really cool performance hacks, and written some great blog posts[1] along the way.
I was a bit surprised by a simple test I just ran on a Linux 3.10 tree:
time rgrep aes . > /dev/null
real 0m0.900s
user 0m0.548s
sys 0m0.340s
# Somewhat similar output to ag:
time rgrep -n --color aes . > /dev/null
real 0m1.177s
user 0m0.876s
sys 0m0.288s
time ag aes > /dev/null
real 0m1.147s
user 0m1.040s
sys 0m0.548s
# Using fixed strings in grep, limiting us to searching c-files
time rgrep -n --color -F --include='*.c' aes . > /dev/null
real 0m0.936s
user 0m0.720s
sys 0m0.208s
time ag -G \.c aes > /dev/null
real 0m1.130s
user 0m1.140s
sys 0m0.428s
This is on an encrypted volume sitting on top of a low end SSD, all runs
with hot chache. The times here are from ag in Debian -- I tried a build
from upstream git -- but with essentially the same time.
I guess ag might make sense under OS X -- but there doesn't appear to be
any (speed) advantages under GNU/Linux.
Not quite what you want, but you can restrict the search to filenames matching certain pattern with the -G option. For example, ag <pattern> -G \.c will only search on C files.
This lets me completely tailor the file I search using find's filters (e.g., only search files with a .py extension, and skip .svn/ directory). E.g. assuming I'm in my project's root directory:
find . -name .svn -prune -o -name '*.py' -print | xargs grep -Hi 'string or RE I am looking for'
I'm pretty happy with `find|xargs grep` myself. Of course, I have an alias that hides the arcane incantation away under a single `frep`, but underneath it uses those tried and tested unix tools. An alias is usually simpler to carry with me to new systems as well.
I grant that these other tools are great, but I like using the standard utilities because, among other things, once you learn 'find' and 'xargs' you can piece together all kinds of other commands and you don't have to remember a tool-specific syntax (at least for the 'find' and 'xargs' parts).
Yes, more people need to know about "git grep". Did you know you can do things like `git grep -e foo --and -e bar --and --not -e baz`? "git grep" is great.
It'd be cool to see these sorts of new search tools integrate into the git ecosystem. I wonder how much faster 'git ack' would be than just straight-up ack -- in other words, could ack benefit from any of git's working tree and delta-based optimizations / awareness?
Besides only searching the files in the working tree, and more easily searching previous revisions, there won't be any speed improvements. Even if a file is stored using deltas, you still need to fully reconstruct it (more processing).
For full-file queries, sure. But I could imagine asking temporal questions like "show me changes made in the last month that introduces API x", for example.
If you don't want/have Perl installed or are just a Python aficionado - check out https://github.com/eliben/pss/ - the Python-based ack clone. It's also actively developed.
30 comments
[ 4.9 ms ] story [ 76.8 ms ] threadYou can limit the files it searches with -G <pattern>
in these cases ag is noticeably faster (orders of magnitude, in some cases), especially if you're just searching a literal and not with a regex pattern.
the author has done some really cool performance hacks, and written some great blog posts[1] along the way.
[1]: http://geoff.greer.fm/2012/09/03/profiling-ag-writing-my-own...
I guess ag might make sense under OS X -- but there doesn't appear to be any (speed) advantages under GNU/Linux.
I was actually contrasting it to ack in my speed claims. I don't expect that it'd be that much faster than GNU grep in most situations.
This lets me completely tailor the file I search using find's filters (e.g., only search files with a .py extension, and skip .svn/ directory). E.g. assuming I'm in my project's root directory:
ag -i -G '\.py$' 'string or RE I am looking for'
I grant that these other tools are great, but I like using the standard utilities because, among other things, once you learn 'find' and 'xargs' you can piece together all kinds of other commands and you don't have to remember a tool-specific syntax (at least for the 'find' and 'xargs' parts).
Bundle 'mileszs/ack.vim'
http://sphinxsearch.com/
(A - after, B - before, C - context)