From: Johannes Sixt <j6t@kdbg.org>
Date: Wed, 24 Nov 2010 22:06:17 GMT
Subject: Re: Inexplicably deteriorating performance of Git repositories on Windows
Message-ID: <201011242306.17834.j6t@kdbg.org>
In-Reply-To: <AANLkTi=X724OJgUvG0Ggu3OwxyaJprr9CLL+t+x=MbTO@mail.gmail.com>

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