Re: git performance after directory copy

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Sep 20, 2010, 09:56 UTC
Message-ID: <vpq62y0hh63.fsf@bauges.imag.fr>
In-Reply-To: <C5A8FDEFF7647F4C9CB927D7DEB307730F33B7C9@ahr075s.basler.corp>

"Gaer, A." <Andreas.Gaer@baslerweb.com> writes:

> On a copied source directory "git status" seems to be about
> 3 times slower than on the original directory.

It is expected that the first "git status" be slower. It will most likely have to actually re-diff the files and update the index stat-cache.

But I'm surprised that the next "git status" are still slow. Other people may get a better explanation, but this very much looks like a bug.

Are you sure you don't have any permission problem, like a read-only .git/index?

To investigate a bit, you can play with diff.autorefreshindex. When set to false, "git diff" will tell you about the files which are identical, but do not have the same stat information (and hence, that Git has to re-diff). For example:

$ git config diff.autorefreshindex false $ git diff

# no output: bar.txt exists, but is up to date.

$ touch bar.txt $ git diff

diff --git a/bar.txt b/bar.txt

# No actual diff, but the file appears since its stat information is
# different.

$ git diff
diff --git a/bar.txt b/bar.txt

# Further "git diff" behave the same.

$ git status
...
$ git diff  

# git status did update the stat-cache, hence, no output from git diff
# anymore.

Another diagnosis tool would be "strace -e open git status,lstat64".
For example:

$ touch bar.txt 
$ strace -e open,lstat64 git status |& grep bar.txt
lstat64("bar.txt", {st_mode=S_IFREG|0644, st_size=30, ...}) = 0
open("bar.txt", O_RDONLY|O_LARGEFILE)   = 3
$ strace -e open,lstat64 git status |& grep bar.txt
lstat64("bar.txt", {st_mode=S_IFREG|0644, st_size=30, ...}) = 0

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/