All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <michaeljgruber+gmane@fastmail.fm>
To: git@vger.kernel.org
Subject: Re: update-index --assume-unchanged doesn't make things go fast
Date: Thu, 26 Jun 2008 10:47:09 +0200	[thread overview]
Message-ID: <g3vl2l$qn7$1@ger.gmane.org> (raw)
In-Reply-To: <32541b130806251102l6e71a050o82fbd4f272d1d23f@mail.gmail.com>

Avery Pennarun venit, vidit, dixit 25.06.2008 20:02:
> 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

  reply	other threads:[~2008-06-26  8:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25 16:44 update-index --assume-unchanged doesn't make things go fast Avery Pennarun
2008-06-25 17:38 ` Michael J Gruber
2008-06-25 18:02   ` Avery Pennarun
2008-06-26  8:47     ` Michael J Gruber [this message]
2008-06-25 19:30 ` Jakub Narebski
2008-06-25 19:41   ` Junio C Hamano
2008-06-25 19:53   ` Avery Pennarun
2008-06-25 21:35     ` Jakub Narebski
2008-06-26  1:30       ` Avery Pennarun
2008-06-26 11:22 ` Stephen R. van den Berg
2008-06-27 17:01   ` Avery Pennarun
2008-06-27 17:31     ` Jakub Narebski
2008-06-27 17:56       ` Avery Pennarun
2008-06-27 18:09         ` Dana How
2008-06-27 18:51           ` Avery Pennarun
2008-06-28  2:03       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='g3vl2l$qn7$1@ger.gmane.org' \
    --to=michaeljgruber+gmane@fastmail.fm \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.