On Mittwoch, 24. November 2010, Dun Peal wrote: > So my theory is that there's a cache that on the "fast" machines > aggressively caches the entire tree on a regular `git status` run. On > such a machine, it's enough to run `git status` once, and after that > initial cold run, the rest will be warm... until you reboot the > machine, rinse, repeat. > > On a slow machine, however, cache isn't so aggressive. It might be > write-oriented. So when you write out a whole new working tree, that > tree gets cached as it is written. And for the remainder of the > lifetime of that cache, you get the fully-cached performance you see > on the "fast" machines. But then you reboot the machine, and lose the > cache. And since the caching process isn't aggressive, any number of > `git status` runs won't get you back to the fully cached state. You > will only get that on a newly written working copy. You can test this theory on a slow machine: You have cloned a repository, rebooted, and you are now at 14s per 'git status'. Now: $ git rm -r . $ git reset --hard erases the worktree and writes it out again (do this only on a clean checkout!). Are you now at 5s per 'git status'? -- Hannes -- 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