Re: git grep performance regression

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 15, 2013, 02:46 UTC
Message-ID: <CACsJy8A7FLYqdY2Mt5pUq0nH3N8mbZ4crkYJYFfepp19c0aWhg@mail.gmail.com>
In-Reply-To: <20130114223800.GA12708@hobo.wolfson.cam.ac.uk>

On Tue, Jan 15, 2013 at 5:38 AM, Ross Lagerwall <rosslagerwall@gmail.com> wrote:

Show 19 quoted lines

> Hi,
>
> 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

Interesting. I see the regression on linux-2.6 too (0.6s real vs 0.9s).

Show 13 quoted lines

> 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.

Not the real contributor to the regression, but it should be noted that glibc's strrchr does not employ a typical loop. Instead it advances with strchr with a note that strchr is much faster. It looks like strchr compares a word at a time instead of a byte. We might want to do the same.

I don't have time to look into details now, but by enabling DEBUG_ATTR, it looks like this commit makes it push and pop patterns a lot more than without the commit.

-- 
Duy