Why is committing code so much faster than running diff?

Question

I like to check my commits before I push them upstream, so I always run a gitk (I like a little visual) before committing. I've noticed, though, that it's much quicker to commit the code first and then run gitk.

Slower:

[with uncommitted changes]
gitk
review uncommitted changes

Quite a bit faster: (haven't timed it, but it seems instant, as opposed to a few second lag)

git commit
gitk
review last commit
Revert or amend as necessary.

My understanding was the git basically runs a diff when it creates commits. So why does it take so much longer to diff the uncommitted code than to commit and review the last commit?

I'll try to time it when my repo is dirty :). I'd say git diff takes about 3 or 4 seconds — Ben Jacobs, Feb 11 '14 at 23:20
What filesystem / disk are you using? How many files in the repository? — Dietrich Epp, Feb 11 '14 at 23:28
*"How many files in the repository?"* -- Just for reference, even diffing the Linux kernel source tree doesn't even take half a second for me. — Dolda2000, Feb 11 '14 at 23:29
The repo is large, but not that large. It has about 10,000 files and is just over 400mb. I have it checked out onto a virtualized copy of Windows 7, running on a Macbook pro. — Ben Jacobs, Feb 11 '14 at 23:45
@Benmj: It is interesting that you use Windows. Please see the edit to my answer. — Dolda2000, Feb 12 '14 at 04:10
@Dolda2000 That's really interesting, and I'll dig into it more. — Ben Jacobs, Feb 12 '14 at 04:30

score 2 · Accepted Answer · edited May 23 '17 at 12:29

My understanding was the git basically runs a diff when it creates commits.

That, at least, is not true. When committing, Git simply archives the current index, precisely as it is. There are no diffs in a commit; rather, they are produced dynamically each time you actually view a commit.

Therefore, you also have the wrong idea, in a way. When you view your last commit with gitk, gitk actually runs git diff to produce what you see, so if you don't find that slow, then git diff simply isn't slow. :)

If producing a diff of the current working tree is slow, then I suspect that's more of a problem with your filesystem than anything else. I've never found it slow whatsoever, and I even use NFS. (So I must admit I don't quite understand how your filesystem could be much slower than that.)

Alternatively, it might just bit gitk that is slow. I've never used it much for reviewing the current state of the repository, usually preferring git status, git diff and/or git gui instead. (I do use gitk, but almost only to view the history and/or historical commits.)

A couple of tips:

Leave gitk running in the background rather than restarting it every time.
Check if running git diff itself is as slow as starting gitk.
Just to be sure, run a git gc to optimize the repository.

EDIT: Now that you've mentioned that you run use Windows 7, it should be mentioned the Linus has quoted, when commenting on the design of Git, that he has made much use of his knowledge of the Linux kernel filesystem implementation for the speed of Git. The reason, then, for your slowness in comparing the working tree to the index may very well be that Windows 7 either has slower filesystem calls than Linux and/or simply doesn't like the way Git uses the filesystem.

This thread on the Git mailing list seems to be the same problem you're having, only worse. It has this quote, among others:

I think the simple reality is that Git was written with the assumption that stat is cheap and that isn't really the case on Windows, where the filesystem cache doesn't seem to do that well with this.

This answer on SO mentions a patch for msysgit which dramatically improves performance on Windows.

Why is committing code so much faster than running diff?

1 Answers1