On Wed, 2014-05-28 at 23:44 +0200, Michael Haggerty wrote:
> On 05/28/2014 11:04 PM, David Turner wrote:
> > In a repository with tens of thousands of refs, the command
> > ~/git/git-diff-index --cached --quiet --ignore-submodules [revision]
> > is a bit slow. check_refname_component is a major contributor to the
> > runtime. Provide two optimized versions of this function: one for
> > machines with SSE4.2, and one for machines without. The speedup for
> > this command on one particular repo (with about 60k refs) is about 12%
> > for the SSE version and 8% for the non-SSE version.
> Interesting. Thanks for the patch.
Thanks for your thoughtful comments.
> Why do you use "git diff-index" to benchmark your change? Is there
> something particular about that command that leads to especially bad
> performance with lots of references?
Because a colleague specifically asked me to look at it because he uses
it as part of the zsh/bash git prompt dirty bit display. But that is not
actually a good reason to use it in the commit-message. This is also
the reason why milliseconds matter, although at present other parts of
git are slow enough that the prompt stuff is still somewhat infeasible
for large repos.
> I assume that most of the time spent in check_refname_component() is
> while reading the packed-refs file, right?
> If so, there are probably
> other git commands that would better measure that time, with less other
> work. For example, "git rev-parse refname" will read the packed-refs
> file, too (assuming that "refname" is not a loose reference). If you
> test the speedup of a cheaper command like that, it seems to me that you
> will get a better idea of how much you are speeding up the ref-reading
> part. It would also be interesting to see the difference in
> milliseconds (rather than a percentage) for some specified number of
I'll change it to rev-parse and to show the difference in milliseconds.
The times on rev-parse are 35/29/25ms on one particular computer, for
original, LUT, SSE. So, somewhat larger speedup in percentage terms. I
should also note that this represents a real use-case, and I expect that
the number of refs will be somewhat larger in the future.
> I think it's worth using your LUT-based approach to save 8%. I'm less
> sure it's worth the complication and unreadability of using SSE to get
> the next 4% speedup. But the gains might be proven to be more
> significant if you benchmark them differently.
I was actually hoping at some point to use SSE to speed up a small few
of the other slow bits e.g. get_sha1_hex. I have not yet tested if this
will actually be faster, but I bet it will. And my watchman branch uses
it to speed up the hashmap (but it seems CityHash works about as well so
I might just port that instead).
But actually speaking of SSE: is there a minimum compiler version for
git? Because I have just discovered gcc-4.2 on the Mac has a bug which
causes this code to misbehave. Yet again, compiler intrinsics prove
less portable than straight assembly language. I would be just as happy
to write it in assembly, but I suspect that nobody would enjoy that. I
could also work around the bug with a compiler-specific ifdef, but Apple
has been shipping clang for some years now, so I think it's OK to leave
the code as-is.
> I won't critique the code in detail until we have thrashed out the
> metaissues, but I made a few comments below about nits that I noticed
> when I scanned through.
I'll go ahead and roll a new version with the nits picked.
> Please add a comment here about what the values in refname_disposition
> signify. And maybe add some line comments explaining unusual values,
> for people who haven't memorized the ASCII encoding; e.g., on the third
I think I'm going to say, "see below for the list of illegal characters,
from which this table is derived.", if that's OK with you.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html