Re: git grep performance regression

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 15, 2013, 02:48 UTC
Message-ID: <7v622z6u1g.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130114223800.GA12708@hobo.wolfson.cam.ac.uk>

Ross Lagerwall <rosslagerwall@gmail.com> writes:

Show 35 quoted lines

> I have noticed a performance regression in git grep between v1.8.1 and
> v1.8.1.1:
>
> On the kernel tree:
> For git 1.8.1:
> $ time git grep foodsgsg
>
> real   0m0.158s
> user   0m0.290s
> sys    0m0.207s
>
> For git 1.8.1.1:
> $ time /tmp/g/bin/git grep foodsgsg
>
> real   0m0.501s
> user   0m0.707s
> sys    0m0.493s
>
>
> A bisect seems to indicate that it was introduced by 94bc67:
> commit 94bc671a1f2e8610de475c2494d2763355a99f65
> Author: Jean-Noël AVILA <avila.jn@gmail.com>
> Date:   Sat Dec 8 21:04:39 2012 +0100
>
>     Add directory pattern matching to attributes
>     
>     The manpage of gitattributes says: "The rules how the pattern
>     matches paths are the same as in .gitignore files" and the gitignore
>     pattern matching has a pattern ending with / for directory matching.
>     
>     This rule is specifically relevant for the 'export-ignore' rule used
>     for git archive.
>     
>     Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>

Hmph, that looks really bad, especially given that in the normal codepath like "git grep", we would never care about directories (the attributes are normally applied to real paths with contents, and the use by archive is an anomaly) and the implementation should be done in a way not to impose such excess and useless overhead.

We may end up reverting that patch for the time being X-<.

Jean-Noël, ideas?