On Thu, 13 Nov 2008, James Pickens wrote: > > Is there any way to improve 'git status' performance on nfs? I know nothing > about how that code works, but if it's strictly serial, i.e. it waits for the > result of each lstat() before doing the next lstat(), then perhaps it could be > sped up by overlapping the lstat() calls via multi threading. It's fairly doable. "git status" to some degree is actually the worst case, since it has to do readdir()'s etc to find new files, but I've occasionally considered trying to do a parallel version of the regular index file checking where we have the list of files a priori. That would speed up "git diff" by potentially a big amount (it would also speed up git status, just not as much as also doing readdirs in parallel). However, every time I think about it, I end up looking at my own setup which has effectively no parallelism. Sure, in theory parallel reads can help even with a local disk, but in practice the potential seek advantage is very small, and so I've never really had it as a high priority. If I were still using NFS (I gave up on it years ago exactly because it was so painful for software development - and that was when I was using CVS) I'd surely have done it long since. Bit I'll think about it again. 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
