On Sun, 17 May 2009, Linus Torvalds wrote: > > That said, on my laptops, CPU time really _never_ is the issue. Every > single time something is slow, the issue is a slow 4200rpm disk that may > get 25MB/s off it for linear things in the best case, but seeks take > milliseconds and any kind of random access will just kill performance. Side note - I've several times desperately tried to see if IO parallelism helps. It doesn't. Some drives do better if they get many independent reads and can just do them concurrently. Sadly, that's pretty rare for reads on rotational media, and impossible with legacy IDE drives (that don't have the ability to do tagged queueing). So when I try to do IO in parallel (which git does support for many operations), that just makes the whole system come to a screeching halt because it now seeks around the disk a lot more. A similar issue that often kill parallelism on CPU's (bad cache behavior, and lots of outstanding memory requests) kills parallelism on disks too - disk performance simply is much _better_ if you do serial things than if you try to parallelize the same work. It would be different if I had a fancy high-end RAID system with tagged queueing and lots of spare bandwidth that could be used in parallel. But that's not what the git usage scenario often is. All the people pushing multi-core seem to always ignore the big issues, and always working on nice trivial problems with a small and well-behaved "kernel" that has no IO and preferably didn't cache well even when single-threaded (ie "streaming" data). 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