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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html