On Mon, 19 Mar 2007, Junio C Hamano wrote:
quoted text
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html