On Thu, 23 Jul 2009, Carlos R. Mafra wrote:
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html