Re: New features in gitk

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 1, 2007, 16:21 UTC
Message-ID: <alpine.LFD.0.999.0711010910090.3342@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.999.0711010844260.3342@woody.linux-foundation.org>

On Thu, 1 Nov 2007, Linus Torvalds wrote:

Show 5 quoted lines

> 
> The hot-cache numbers are already pretty damn good. But try this:
> 
> 	echo 3 > /proc/sys/vm/drop_caches
> 	gitk

Actually, do the above with a path limiter, to make it more obvious.

So try this on the kernel, and you'll see the difference even with a fast disk, and even if it's fully packed:

	echo 3 > /proc/sys/vm/drop_caches
	time git rev-list HEAD drivers/scsi | head -10

and now try it with --topo-order.

I get ten seconds with --topo-order (because it has to traverse the *whole* history even to just generate the first ten lines), while the non-topo-order case is *three*times* faster.

On my laptop, it's even more noticeable. I don't know quite why, but the non-topo-order case is actually faster on my laptop than on my desktop (will have to see what's up, but I suspect it's a result of they being at different points in history, and just bad luck wrt the top-of-history having happened to change drivers/scsi or not):

	[torvalds@t40 linux]$ time git rev-list HEAD drivers/scsi | head -10
	..
	real    0m0.688s

but with --topo-order it's much slower:

	[torvalds@t40 linux]$ time git rev-list --topo-order HEAD drivers/scsi | head -10
	..
	real    0m17.458s

See? You shouldn't care about CPU usage, you should care about IO costs! Those are the first-order effects.

In other words, if you can be incremental, we're talking about performance differences that are orders-of-magnitude. Not ten percent or something piddling like that! And the performance improvemens come for the cases that are the _problem_, rather than the cases that already work perfectly well.

				Linus