On Sun, Jan 9, 2011 at 18:17, Aristotle Pagaltzis <pagaltzis@xxxxxx> wrote: [CC'd Andy & the Git list in case they're interested] > * Aaron Crane <perl@xxxxxxxxxxxxxxxx> [2011-01-09 13:10]: >> AFAICT, the most important reason for the speed of `git grep` >> is that (in recent versions, at least) it uses multiple >> threads. [â] I believe that ability should be reasonably easy >> to reimplement in a Perl grep-a-like > > I assumed, on no factual basis, that one of the reasons is that > it uses the object store whenever possible instead of the working > copy, which would speed up `git grep` in much the same way it > makes `git checkout` faster than `cp -R`. (Compression and linear > pack files reduce I/O.) I donât know if thatâs actually the case, > though. But such an avenue is not open to generic grep clones. Yes, this is correct. git-grep(1) is fast because it doesn't have to do the I/O that grep(1) and ack(1) have to do. It can just read the git tree/object files. Incidentally (since I also work on git.git) one idea for a project I had was to add a new plumbing command that does the grep-like things git-grep(1) does but allow someone to implement their own grep-er. I.e. just spew out filename/line pairs on stdout. Then e.g. ack(1) could use this new plumbing command to read files when in a git repository, but could provide Perl's regex features and other things it has. But last I looked Ack was fairly unmodularized, so adding that sort of stuff might be hard. But that might have changed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html