Re: git performance
- From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
- Date
- Oct 23, 2008, 13:04 UTC
- Message-ID
- <fcaeb9bf0810230604u6db6d31cr91153b3cbfa0bbb6@mail.gmail.com>
- In-Reply-To
- <49002B27.50201@op5.se>
On 10/23/08, Andreas Ericsson <ae@op5.se> wrote:
Show 34 quoted lines
> 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