Re: update-index --assume-unchanged doesn't make things go fast
- From
Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
- Date
- Jun 26, 2008, 08:47 UTC
- Message-ID
- <g3vl2l$qn7$1@ger.gmane.org>
- In-Reply-To
- <32541b130806251102l6e71a050o82fbd4f272d1d23f@mail.gmail.com>
Avery Pennarun venit, vidit, dixit 25.06.2008 20:02:
Show 19 quoted lines
> On 6/25/08, Michael J Gruber <michaeljgruber+gmane@fastmail.fm> wrote: >>> 4) My idea is to eventually --assume-unchanged my whole repository, >>> then write a cheesy daemon that uses the Win32 dnotify-equivalent to >>> watch for files that get updated and then selectively >>> --no-assume-unchanged files that it gets notified about. That would >>> avoid the need to ever synchronously scan the whole repo for changes, >>> thus making my git-Win32 experience much faster and more enjoyable. >>> (This daemon ought to be possible to run on Linux as well, for similar >>> improvements on gigantic repositories. Also note that TortoiseSVN for >>> Windows does something similar to track file status updates, so this >>> isn't *just* me being crazy.) >> Looks like users on slow NFS would profit, too. Hate to say it, but hg >> feels faster on (slow) NFS than git. Yet I use git, for other reasons ;) > > Hmm, can you do dnotify over NFS? > > I'd like to know how hg goes any faster. As far as I can see, git is > going as fast as can be without some kind of daemon or other magic. > (Except for my point #3, which seems relatively minor.)
I haven't done any measurements, maybe I should; getting consistent results would require setting up an isolated NFS environment, though.
The thing is that hg is very careful about serializing and minimizing disk I/O, whereas git is very clever about delegating stuff to the kernel and processing data efficiently. In my work environment I have to keep my repos on NFS. For heavy history rewriting I resort to /tmp or /dev/shm temporarily. But git status is kinda slow on NFS. I don't know about [di]?notify over NFS.
Michael