monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: Re: linus talk on git


From: Pavel Cahyna
Subject: [Monotone-devel] Re: Re: linus talk on git
Date: Tue, 29 May 2007 21:41:05 +0200
User-agent: mutt-ng/devel-r529 (NetBSD)

Hello,

On Tue, May 29, 2007 at 03:38:57AM -0700, Nathaniel Smith wrote:
> On Tue, May 22, 2007 at 08:19:33PM -0600, Derek Scherger wrote:
> > In terms of performance, I did a very quick test today on a ~30,000 file
> > tree and git status took ~0.6 seconds while monotone (with inodeprints
> > on) took ~3.5 seconds. Personally, ~3.5 seconds doesn't really offend me
> > and I'm curious as to how much sha1 consistency checking git is doing
> > generally when compared with monotone. I suspect it's doing somewhat
> > less verification of things.
> 
> Eek, we should fix that.  (And 0.6s vs. 3.5s is the difference between
> "instant" and "twiddle-twiddle-twiddle" in user experience terms.)
> We have no excuse for going 6 times slower on status; we should be
> (and at some point were) fast-pathing everything so we pay no penalty
> for using more structured design.  (Probably this is related to that
> other thread about doing 4x too many stat calls, etc...)

I also observe very poor scaling down of the status command. I have a
workspace with 17507 files. There is a subdirectory with 17 files. In this
subdirectory:

$ time mtn status .
(...)
   71.72s real    68.37s user     0.81s system

$ time mtn status
(...)
   91.40s real    85.19s user     1.78s system

For comparison: the same 17 files, from a CVS repository. cvs has to
contact a remote server across the Atlantic.

$ time cvs status
(...)
    8.70s real     0.14s user     0.09s system

This is lame. Why should status of 17 files take almost the same time as
status of 17507 files?

Pavel Cahyna




reply via email to

[Prev in Thread] Current Thread [Next in Thread]