Re: Git performance on OS X

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Apr 19, 2008, 21:54 UTC
Message-ID: <alpine.LFD.1.10.0804191443550.2779@woody.linux-foundation.org>
In-Reply-To: <1208633300-74603-1-git-send-email-pdebie@ai.rug.nl>

Btw, the "git status" issue is totally different.

On Sat, 19 Apr 2008, Pieter de Bie wrote:

Show 11 quoted lines

>
> Now we can look at the "git status" commands and compare them to the actual
> status' of the actual webkit repository.
> 
> Results
> ======================================================================
> Command                                            Mean     Std    
> git status                                         4.573  0.514
> git status .                                       13.515  0.448
> hg status                                          4.411  1.594
> hg status .                                        4.903  0.171

The reason "git status ." is slower has nothing to do with the pathspec matching, and everything to do with the fact that "git status" with a pathspec means soemthing different again.

Remember: "git status" is basically shorthand for "what would happen if I 
did a "git commit" with these arguments.

Which means that "git status ." basically is something similar to a private invocation of "git add -u ." in addition to the regular git status.

So try it out: change some file (let's say the top-level Makefile) and do the two operations, and see how the _output_ is totally different:

Without the ".", you should see something like:

	# On branch master
	# Changed but not updated:
	#   (use "git add <file>..." to update what will be committed)
	#
	#       modified:   Makefile
	#
	no changes added to commit (use "git add" and/or "git commit -a")

ie there is nothing to commit, but Makefile is modified and _could_ be committed.

Now, don't look down at the answer, but instead try to think it through: what is "git status ." going to say?

Answer: it's going to show something totally different, because "git 
commit ." is going to add that changed Makefile to the commit, so by the 
logic that "git status" is supposed to show what commit will do, you'll 
*not* see that "no changes" line at all, but instead you'll see

	# On branch master
	# Changes to be committed:
	#   (use "git reset HEAD <file>..." to unstage)
	#
	#       modified:   Makefile

ie now we *would* commit that Makefile change!

So the reason "git status ." is more expensive is that it's doing something else.

I don't know what "hg status ." means, but I suspect that it's more of a "same thing as 'hg status', but limited to '.'".

And yes, most of the time in "git status ." is going to be the lstat() calls. Which are expensive on OS X. And yes, we do too many of them. I'll look at seeing if we can avoid some.

		Linus