Re: Performance issue of 'git branch'
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Jul 23, 2009, 16:19 UTC
- Message-ID
- <alpine.LFD.2.01.0907230913230.21520@localhost.localdomain>
- In-Reply-To
- <20090723160740.GA5736@Pilar.aei.mpg.de>
On Thu, 23 Jul 2009, Carlos R. Mafra wrote:
Show 19 quoted lines
>
> Having learned about .git/packed-refs last night, today I tried
> this (with cold cache),
>
> [mafra@Pilar:linux-2.6]$ time awk '{print $2}' .git/packed-refs |grep heads| awk -F "/" '{print $3}'
> 0.00user 0.00system 0:00.12elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (3major+311minor)pagefaults 0swaps
> 27-stable
> 28-stable
> 29-stable
> 30-stable
> dev-private
> master
> option
> sparse
> stern
>
> and notice how that makes my pitiful harddisc look like Linus' SSD! And the
> result is the same. The result is the same, yes, but it doesn't do error checking.
What "git branch" does over and beyond just looking at the heads is to also look at the commits those heads point to. And the reason it sucks for you is that the commits are pretty spread out (particularly in the index file, but also in the pack-file) on disk. So each "verify this head" will likely involve at least one seek, and possibly four or five.
And on your disk, five seeks is a tenth of a second. You can run hdparm, and it will probably say that you get 30MB/s off that laptop drive - but when doing small random reads you'll probably get performance in the order of a few tens of kilobytes, not megabytes. (With read-ahead and read-around it's probably going to be mostly ~64kB IO's and you'll probably get hundreds of kB per second, but you're going to care about just a few kB total of those).
So we _could_ make 'git branch' not actually read and verify the commits. It doesn't strictly _need_ to, unless you use 'git branch -v' or something. That would speed it up further, but the verification is nice, and as long as performance isn't _horrible_ I think we're better off doing it.
After all, you'll see the problem only once.
Linus