On Thu, 1 Nov 2007, Linus Torvalds wrote: > > 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 - 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
