Anyone have a sense of how the new Ack 2.0 compares to The Silver Searcher[1] (aka Ag)? I've been using TSS for some time now and it's been completely awesome in both performance and functionality compared to Ack v1.
I had never heard of The Silver Searcher. Thanks! A test search of a huge codebase (Firefox) took 38 seconds with ack, but only 17 with ag! After my page cache had been warmed up, ack then took 10 seconds and ag only took 3. That said, I am using ack 1.96, not ack 2.0.
It's OK to have two similar tools in your toolbox. When you need the --output option, for example, you use ack. When you want crazy speed, you use ag.
You don't have to choose one over the other. That's why I changed the name from "betterthangrep.com" to "beyondgrep.com". There's no need to have a ranking of "I use this over that."
Turning things around, I often have SQL dumps around, so ack --no-sql is a real lifesaver in my Rails (i.e ruby, coffee, less, shell and whatnot) projects.
Though I've switched to ag, I still miss Ack's selection and deselection flags. Those are much sweeter than ag's -g and -G and it looks like they've improved further
It would be interesting to see benchmarks on this. I know TSS was faster before, and this release didn't seem to highlight any performance improvements.
Chances are that if there are any performance changes, it might even be a decrease in speed because of having to find .ackrc files. We haven't gone profiling 2.0 yet, but that's near the top of our list.
That's pretty much what I figured. If we wait a bit, I wouldn't be surprised to see a writeup from Geoff, the author of Ag. His blog posts when he started development on it were really interesting.
When it comes to improving Ag's speed, there's not much more to write about. I've used every dirty trick I know: mmap()ed I/O, threads, Boyer-Moore-Horspool strstr(), PCRE-JIT, etc. Now when I profile, Ag spends the majority of its time reading files off disk. On most systems, this is true even if the files have been cached in memory by the OS. The limiting factor is memory bandwidth.
Anyways, I don't really have the time for long analysis posts these days. I'm busy working on something that captures value in addition to creating it. :)
ack has been an indispensable tool in my workflow for a few years now. I use it several times a day to search code bases... most of the time, not even taking advantage of regexes or all of its many abilities. Just a basic keyword search is usually enough; the output looks great.
The feature I've wanted the most is the local project-specific .ackrc ability. I have some projects where I need to be able to ignore specific files/dirs; I think this feature will address that need.
The silver searcher (Ag)[1] ignores files from .gitignore/.hgignore by default, so I find that this sort of project-specific configuration isn't generally needed. There are various editor plugins for Ag, e.g. Ag.vim[2] based on mileszs' excellent Ack.vim[3].
Editor integrations fail badly with big codebases though. I don't use sublime text, but I can't imagine getting it to index, say, the entire kernel (or the /frameworks subtree of an Android build, etc...) faster than a recursive grep will return.
That said, I don't use ack. I've tried it a few times and it looks great and works well, but honestly this particular task turns out not to be one where I demand polish and features. Really, all I want is grep.
me too, i've tried ack several times but i'm not stuck to it because i've always been able to find anything i was searching for with, tataaa : simple grep and locate.
I use Sublime as my editor as well. Sublime's search functionality is pretty good too, and I can't there's anything bad about it, for my typical use cases... but I've become very used to reaching for ack, and I love the highlighting it uses. On the other hand Sublime does support double click to open on file names in search results.
Ack is wonderful example of tool use evolution.
Before ack, I used grep to find stuff, but each use would frequently require additional options to exclude certain types of files, then coupled with a pipe to filter other stuff, etc, etc. After ack, everything is much simpler; just specify what you want. It has replaced most of my grep invocations. Honestly, if you work on the command line and use grep, you owe it to yourself to try ack. You (probably) won't look back.
Vim users, don't forget the included vimgrep. It greps your file. But the nice thing is, it puts the results in the quickfix window (where your compiler errors go, for example).
I keep a project log file in restructured text. My entry headers look like this:
2013.03.17 Sunday, Set up base box
==================================
When you filter that file with rst2html, your output file can have a table of contents, but not your source file where you probably spend more time.
Use vimgrep to find all your headers:
:vimgrep /^20[0-9][0-9]/gj %
Nothing happens, but the result is in the quickfix window.
:copen
And now you have a second window with entries like the following:
log.rst|1559 col 1| 2013.03.17 Sunday, Set up base box
log.rst|1624 col 1| 2013.03.14 Thursday, configured widgets
In the quickfix window, enter on any line and it brings you back to the main window, at that location.
:help vimgrep
:help quickfix
:help copen
:help cc
:help cn
We have a really big C++ codebase at work and I find codesearch[1] to be the best way to search through the code, although the UX is terrible compared to Ack/Ag. Another problem is that it's written in go; so hard to get builds for the AIX PPC machines. Faster than everything though -- running a complex regex against 2-3 million SLOC and getting an answer within a second is certainly worth something.
I put in a redirect from http://betterthangrep.com/ack-standalone to the new location, but it's temporary. I never intended for anyone to use that command line as ad hoc API, nor did I realize that people were scripting against it. :-/
So, sorry I broke it, and, I can't promise that URLs are going to stay where they are unless I explicitly say that I am promising that.
Sweet. I'm a complete ack convert - `ack 'some str' --no-haml` (which, in rails project roots, will ignore specific build folders because of my .ackrc file) is just so much easier and more readable than the grep equivalent, it's hard to go back.
I couldn't do my job without ack. We have a code base with millions of lines of C/C++ and tons of PHP. I use ack every day to find code and files. I've been looking forward to 2.0 for a long time. Will try to help melt his server right now :)
I stopped using ack because it opens the same files several times (strace it to see for yourself - I've seen version 1.94 open the same file 17 times) and has problematic performance on our a little higher latency setup (Xen + FC storage). ag does everything I need and has no such issues...
I haven't used either one, but from reading the descriptions it sounds like ag has fewer features, for examples it doesn't have the --output option to tailor how results of matches are presented. On the other hand, it sounds like it should be faster.
Depends on what your needs are. Do you want the coloring and grouping? Do you want Perl regular expressions? Do you want to only search source code? Do you want to be able to specify specific filetypes, like "ack foo --perl" or "ack foo --nohtml"?
git grep is neither superset nor subset of ack. Each tool has its place.
If you prefer Python and don't want to have Perl around just for the sake of 'ack', check out 'pss' - a similar tool written in pure Python: https://bitbucket.org/eliben/pss
[sorry for the plug, but it's definitely relevant to the discussion]
Actually my initial motivation for developing pss was Windows. I had to use Windows at work at the time, and installing Perl just for the sake of ack was pain. ack also needs an additional module from CPAN (for console coloring), so double pain.
Python, OTOH, is always one of the first I install on every machine that doesn't have it :) pss requires no installation, no additional modules, just Python.
Aside from embedded/routers and Windows machines, it's few and far between. At the very least you're going to have something ancient like Perl 5.6 or 5.8 installed.
[1] https://github.com/ggreer/the_silver_searcher