Linus Torvalds [off-list ref] writes:
So it looks like it *used* to be somewhat of a problem (the object access
itself must have been about 10 seconds, since that got shaved off the
time), but realistically, if you want to speed up "git blame", we can
totally ignore the git object data structures, an dconcentrate on xdiff
and on blame itself (cmp_suspect and assign_blame probably have some nasty
O(n^2) behaviour or something like that,...
With this stupidity-removal patch, it gets down to 7.80user from
8.72user (comparable number of minor faults) for blaming
block/ll_rw_blk.c (without tglx grafts)
diff --git a/builtin-blame.c b/builtin-blame.c
index b51cdc7..104521e 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -182,9 +182,8 @@ struct scoreboard {
static int cmp_suspect(struct origin *a, struct origin *b)
{
- int cmp = hashcmp(a->commit->object.sha1, b->commit->object.sha1);
- if (cmp)
- return cmp;
+ if (a->commit != b->commit)
+ return 1;
return strcmp(a->path, b->path);
}
On Mon, 19 Mar 2007, Junio C Hamano wrote:
With this stupidity-removal patch, it gets down to 7.80user from
8.72user (comparable number of minor faults) for blaming
block/ll_rw_blk.c (without tglx grafts)
Yeah, this one works for me too. Even more than for you. For me,
git blame --incremental -C HEAD block/ll_rw_blk.c
takes 6.71s (best of ten) normally, and 4.85 (best of ten again) with your
patch and Nico's one-liner. In fact, that's a much bigger improvement than
I would have expected from the profile, but it may be that you just cut
the data cache footprint down a lot, and thus made other things more
efficient.
(I just double-checked. Nico's one-liner does help, but not nearly as
radically as it did for Nico. The "best of ten" with *just* Nico's
one-liner is 6.22 for me - better than before, but the combination of
Nico's patch and yours is much more dramatic).
Btw, Dscho's slightly more invasive patch seems to *just* edge out Nico's
one-liner for me, with best-of-ten being 6.17s.
The winner is your patch *with* Dscho's slightly more invasive one: 4.69s.
But the difference between the numbers of Dscho's bigger patch and Nico's
one-liner really are totally in the noise. Dscho *just* wins the
best-of-ten both with and without your patch, but in both cases it's
*way* in the noise. For example, while 4.69s was the best for your+Dscho
in my testing, the full series was
0:05.69
0:04.69
0:04.82
0:04.97
0:04.85
0:05.88
0:04.77
0:04.69
0:05.12
0:04.98
so the variability was big enough that I wouldn't say that 0.1s is really
all that meaningful even for "best of ten". I didn't try to make the
machine totally quiescent, I've got xmms playing in the background etc..
But these kinds of things will definitely vary from machine to machine.
It's all good, though.
Linus
Linus Torvalds [off-list ref] wrote:
Btw, Dscho's slightly more invasive patch seems to *just* edge out Nico's
one-liner for me, with best-of-ten being 6.17s.
Uh, instead of Nico here don't you mean DrNick on #git? He is in
real life Nicholas Miell. Google says he's somewhat active in the
kernel world, so maybe you know him? ;-)
--
Shawn.
On Tue, 20 Mar 2007, Shawn O. Pearce wrote:
Linus Torvalds [off-list ref] wrote:
quoted
Btw, Dscho's slightly more invasive patch seems to *just* edge out Nico's
one-liner for me, with best-of-ten being 6.17s.
Uh, instead of Nico here don't you mean DrNick on #git? He is in
real life Nicholas Miell. Google says he's somewhat active in the
kernel world, so maybe you know him? ;-)
I actually meant you.
For some reason, I confuse you and Nico. I've done it several times, and
even without any DrNick mention.
Time to take my meds,
Linus