On Mon, Sep 11, 2000 at 02:08:42PM -0700, Larry McVoy wrote:
>
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > Err, "faster"? The following is the moral equiv of 4 kernel updates
> > > which had nothing to do using BitKeeper instead of CVS. The local copy
> > > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > > over a 384Kbits/sec link. All 4 updates in 5 seconds. Anyone have a
> > > CVS tree they can try to get comparable numbers?
> >
> > Try: http://innominate.org/~tgr/projects/lksr/
>
> Thanks, that was helpful. Comparison numbers for a null update of the 2.3
> kernel, which means you update and then update again, timing the second update
> to get some idea of the system's best case throughput, are:
>
> CVS: 139.5 seconds
> BK: 1.6 seconds
In fairness to CVS, I ran this a third time and got 78 seconds, so the net
must have been busy. It's still about a 50:1 performance difference.
On the other hand, if you do a
find . -type f | xargs touch
time cvs update .
it will melt down your DSL line for what seems forever. I killed it after
20 minutes, I have better things to do with my bandwidth. It's pretty
clear that CVS is comparing timestamps so if your files get modified at
all, it's going to transfer them to see what needs to be updated. The
same sort of "touch all, then update" operation in BK has no effect on
performance, BK doesn't do its work that way.
-- --- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST