Re: Fix extraneous lstat's in 'git checkout -f'

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 13 Jul 2009, Linus Torvalds wrote:
> 
> But if both CE_UPTODATE is set, and CE_VALID is clear, then we know that 
> the lstat() will always match the cache entry information, and there's no 
> point in doing another one.

Perf data on the kernel tree and my machine with index preloading:

 - run-of-ten "git checkout -f" before:
	real	0m0.131s
	real	0m0.130s
	real	0m0.128s
	real	0m0.127s
	real	0m0.129s
	real	0m0.135s
	real	0m0.129s
	real	0m0.126s
	real	0m0.128s
	real	0m0.127s

 - run-of-ten "git checkout -f" after:
	real	0m0.105s
	real	0m0.098s
	real	0m0.098s
	real	0m0.116s
	real	0m0.099s
	real	0m0.104s
	real	0m0.097s
	real	0m0.107s
	real	0m0.105s
	real	0m0.101s

so this makes about a 25% performance difference.

HOWEVER! Without preloading, there is bsically no difference what-so-ever, 
because the index won't have been preloaded (duh), so the CE_UPTODATE bit 
won't be set, so we'll do the lstat() in that oneway_merge() function 
regardless.

S for that non-preloading case, I get

 - run-of-ten "git checkout -f" without preloading:
	real	0m0.115s
	real	0m0.116s
	real	0m0.117s
	real	0m0.118s
	real	0m0.120s
	real	0m0.116s
	real	0m0.110s
	real	0m0.110s
	real	0m0.119s
	real	0m0.117s

so what happens is that with that patch the preloading is finally actually 
faster, because now it really helps do the lstat() in parallel (and I have 
lots of cores).

Before the patch, it would do the lstat first in parallel, but then it 
would do _another_ lstat() in the serial code anyway due to the silly 
oneway_merge() thing wasting time on the lstat() even if it didn't need 
to.

I guess I should have made this issue with preloading clear in the commit 
message. 

In other words - the patch should be _much_ more noticeable if you're 
doing something like NFS and are using core.preloadindex=true. My numbers 
above are all hot-cache, so there's no IO, just the fast multi-core CPU.

			Linus