David A. Gatwood wrote:
> I'm sorry, but I can't believe those numbers. It takes longer than 1.6
> seconds to stat all the kernel directories unless the BK machine has a
> huge disk cache. It sounds like the BK server was a much more powerful
> machine.
Use treescan for fast stat preload :-) Anyway, of course all the stat
info is in cache. This is a null update run after another null update...
> 1. Raw checkout of a full tree
> 2. Raw checkin of a full tree
>
> and does not include a "null update", as that is an atypical usage pattern
> for most trees that unfairly skews the test towards software or kernels
> that does caching of file stat results, which has little bearing on
> typical use.
Actually "null update" is quite typical of CVS usage. You do it often
(like, daily or more) to keep up to date with recent changes, and
definitely before submitting a patch.
When there are changes, "nearly null update" is closer to what happens.
Do you really do full checkouts and checkins that often? I don't on the
CVS projects I manage.
> Critically, the test should be with two otherwise identically configured
> servers and two identically configured clients, across identical networks.
> Only then do the tests mean anything. I'd be very curious to see the
> results. :-)
BK should be faster simply because it's designed to be fast.
However, let's try another project: GCC.
I am at CERN in Switzerland. Good net connection but transatlantic.
Ping time 300-400ms to anoncvs.cygnus.com.
Just now, I did "cvs update" from the EGCS project repository.
real 0m36.738s
user 0m6.790s
sys 0m4.070s
Quite a lot of files were updated. I did "treescan -stat -silent ." to
pull stat information into my local cache first.
Now here's a "null update":
real 0m8.786s
user 0m2.240s
sys 0m0.520s
The timing is typical over repeated tries. The GCC tree contains 98.1
megabytes of data in 9105 files, 532 directory. A little more than
Linux (but I don't have an unpacked fresh tree to count for sure).
I'm not going to try touching all the files.
Conclusion: CVS is pretty fast when not many files have changed.
Comparable with BK. Just don't touch all your local files!
-- Jamie
-
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