Grin: A smarter way to grep code | Hacker News Reader

Grin: A smarter way to grep code

pypi.python.org

19 pointsmace11 comments

My preferred programmers grep: http://petdance.com/ack/

Though rkern is a very clever fellow, and I'm sure grin is sufficiently awesome. I think I'll benchmark the two...I kinda suspect ack is faster, but maybe Python will surprise me (when I used to work in Python a few years ago, I was occasionally disappointed in its performance for tasks like this).

Interestingly, grin uses the exact same output format as ack...same colors and all.

And, yep, ack is quite a bit faster:

    $ time ack joe
    real    0m1.708s
    user    0m1.308s
    sys     0m0.348s

    $ time grin -d .svn joe
    real    0m6.066s
    user    0m5.191s
    sys     0m0.802s

Looks like grin is trying to deal with things that ack doesn't (binary files, for example), so perhaps that's a factor.

And, of course, grep (when massaged appropriately to make it only search the bits we really want) is faster still:

    $ time find * -name '.svn' -prune -o -type f -exec grep joe \{\} +
    real    0m0.412s
    user    0m0.149s
    sys     0m0.189s

So, theoretically, one could wrap that up in an alias, but ack is sufficiently fast, and does enough other cool tricks that I'll just stick with it.

Why not just run `grep -r --exclude=".svn" event *` ? I have a feeling that would be even faster than your concoction...

Either way, I still use `ack` for searching source code, and grep otherwise...

"Why not just run `grep -r --exclude=".svn" event *` ?"

Because it doesn't work, at least not with gnu grep. Try it and see. (Hint: --exclude doesn't do anything with directories...only the files themselves, and .svn is the containing directory. So, using exclude for this purpose merely wastes your time and annoys the pig.)

I guess that's what I get for assuming --exclude works the same between grep and diff...

You probably want to time against fgrep (grep -F). When you're searching for simple strings, it's often faster than the regex grep.

Minor difference:

    $ time find * -name '.svn' -prune -o -type f -exec fgrep joe \{\} +
    real    0m0.365s
    user    0m0.162s
    sys     0m0.183s

But that opens up another can of worms--at least 50% of the time, I'm looking for something more complex (sometimes I'll search for the haystack first using a string, and then switch to a regex to find the needle once I know roughly what I'm looking for). From a productivity standpoint, I think just always using one (probably ack since its output is more readable, though I tend to use grep unless I think, since I haven't been using ack for very long, and ten years of habitual grepping is a habit that dies hard).

I don't understand why a new program was created when a shell alias would suffice. I have a set of grep commands aliased in my .bashrc such that I get the features the author described.

For example:

  alias g="grep -R --exclude 'SVN' --include '*.c' ..."

etc

Some people can write a python program faster than they can figure out all the things they need to do to make grep work the way they want. It's like learning a whole new platform!

gimmie! I'd love to see what you use...

Why rewrite ack? It's already blazing fast and easy to customize even if you're not actually a perl head.

Is there a way to do syntax-driven wildcard matching of Python code?

Reply on news.ycombinator.com