Re: git performance

["Nguyen Thai Ngoc Duy" <pclouds@gmail.com>]

On 10/23/08, Andreas Ericsson <ae@op5.se> wrote:
> Jakub Narebski wrote:
>
> > "Edward Ned Harvey" <git@nedharvey.com> writes:
> >
> >
> > > I see things all over the Internet saying git is fast.  I'm
> > > currently struggling with poor svn performance and poor attitude of
> > > svn developers, so I'd like to consider switching to git.  A quick
> > > question first.
> > >
> > > The core of the performance problem I'm facing is the need to "walk
> > > the tree" for many thousand files.  Every time I do "svn update" or
> > > "svn status" the svn client must stat every file to check for local
> > > modifications (a coffee cup or a beer worth of stats).  In essence,
> > > this is unavoidable if there is no mechanism to constantly monitor
> > > filesystem activity during normal operations.  Analogous to
> > > filesystem journaling.
> > >
> > > So - I didn't see anything out there saying "git is fast because it
> > > uses inotify" or anything like that.  Perhaps git would not help me
> > > at all?  Because git still needs to stat all the files in the tree?
> > >
> >
> > http://git.or.cz/gitwiki/GitBenchmarks
> >
> > While it should be possible to use 'assume unchanged' bit together
> > with inotify / icron, it is not something tha is done; IIRC Mercurial
> > had Linux-only InotifyPlugin...
> >
> >
>
>  Well, inotify() is Linux specific, so it'd be quite hard to support on
>  another platform. Emulating it with a billion stat() calls feels rather
>  like a disk (and I/O performance) killer.

There is "filemon" on Windows, which monitors file access. I don't
know how it impacts performance though. A quick search revealed kqueue
for FreeBSD/Mac OSX.
-- 
Duy