Re: Inexplicably deteriorating performance of Git repositories on Windows

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