[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: hosting git on a nfs
From:       Linus Torvalds <torvalds () linux-foundation ! org>
Date:       2008-11-13 20:18:24
Message-ID: alpine.LFD.2.00.0811131214020.3468 () nehalem ! linux-foundation ! org
[Download RAW message or body]



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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]