I'm not quite, sure. But here's why GNU grep is fast [1]

1. http://lists.freebsd.org/pipermail/freebsd-current/2010-Augu...

In a packed repo, git grep can mmap the pack file once and search through it in one fell swoop. If the pack file isn't already in the filesystem buffer, mmap will get it there quickly. The number of system calls is O(1).

The limitation, as others have said, is git grep won't match files that are not already checked in.

In a regular directory tree, recursive grep has to open and read directories, stat files, and read (or mmap?) each individual file. The number of system calls is O(N) on the number of directory entries.

Not sure if this is the primary reason, but:

"Look for specified patterns in the tracked files in the work tree"

http://git-scm.com/docs/git-grep

Presumably, this would exclude a lot of assets or libraries that aren't part of your branch/repo, don't know what the OP's setup was (are those 11K+ files all tracked?).

After config/parsing, it runs the search at the end of cmd_grep in https://github.com/git/git/blob/master/builtin/grep.c?source...

I don't know the answer to your question, but the git source is simple and rewards reading.

If I were to guess, I would think grep has to traverse the directory tree while git knows all the file names already.

Doesn't git already have a compressed and optimized index of your files?