Performance (Subversion vs. CVS)

I'm looking into Subversion to use at work -- we have a pretty large
CVS repository (5 GB) that feels like its pushing the limits of CVS.
Probably the most obvious reason to change would be for performance --
constant-time branching and tagging are obviously attractive, as are
no-network-required diff and revert.

But I've been playing around with timing "cvs co" and "cvs up" versus
their Subversion counterparts, and the results are not good. In a
nutshell, CVS is 5-15 times faster at checking out and updating working
trees.

Platform: Debian Linux "unstable"
          cvs 1.12.9 (debian 1.12.9-4)
          subversion 1.0.6 (debian 1.0.6-2)

I converted a substantial chunk of our CVS repository (one top-level
directory which accounts for ~600 MB of the ~5 GB total) using cvs2svn.
Took most of a night and day to run, and resulted in a Subversion
repository with:
  ~1100 files (trunk)
  ~9900 revisions
     23 branches
   2407 tags (our CVS workflow is rather tag heavy)

Both the CVS and Subversion repositories are on a pretty fast (ATA100)
IDE disk, and I'm checking out to a pretty fast (Ultra160) SCSI disk.
(I didn't want to fill up my system's primary disk [the SCSI one] with
enormous repositories.) I used local filesystem access everywhere,
eg. "cvs -d /path/to/repos" and "svn co file:///path/to/repos/...".

Here are some timing results from CVS; all times are in seconds, each
measurement repeated 5 times (too lazy to record two decimal places on
the first test, got keen after that):

  initial co 4.1 3.6 3.9 5.4 5.0
  up (no-op) 1.00 0.92 0.87 0.86 1.46
  up -r BETA (from -A) 4.24 3.36 4.21 2.99 4.14
  up -A (from -r BETA) 1.96 2.61 2.12 1.80 2.53
  co -r <recent-branch> 6.83 5.85 5.05 6.31 5.48

The initial checkout was of the same top-level directory that I
converted to a Subversion repository. BETA is a tag that we use for the
"trailing edge" of the trunk, stuff deemed fit for internal builds and
consumption. Switching directories from BETA to the tip of the trunk is
a fairly common occurrence. Checking out recent branches also happens
roughly as often as checking out the trunk. (Not as often as
update/diff/commit, but often enough that I thought it would be worth
timing.)

Now here are the same activities with Subversion 1.0.6:

  co .../trunk 49.3 47.5 46.8
  up (no-op) 1.39 0.54 0.41 2.53 1.17
  switch .../tags/BETA 17.8 19.3 18.0
  switch .../trunk 34.3 35.6 35.7

Wow: the only operation where CVS doesn't completely blow Subversion out
of the water is "update" on a fresh checkout. The fresh checkout itself
is 10x slower with Subversion, and switching back and forth between
tip-of-trunk and BETA is about 5x slower. :-(

This is very disappointing; I was hoping that using an opaque binary
database would at least have slight performance benefits, not an order
of magnitude penalty. Should I at least try out 1.1? Any suggestions
for improving performance of Subversion, short of getting in there with
a profiler myself?

        Greg

-- 
Greg Ward <gward_at_python.net>                         http://www.gerg.ca/
Know thyself.  If you need help, call the CIA.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org