Re: Perforce/Subversion Timing Statistics #2

I'm not sure why I'm replying to this, as it seems like
flamebait... however Joshua has been very polite in his findings. :-)

"Joshua Jensen" <jjensen@workspacewhiz.com> writes:

> No, I don't believe my tests are missing the whole picture. I have
> proven that:
>
> * Adding files to Perforce is significantly faster than Subversion.

This seems true... Berkeley DB is probably the culprit here. I
wouldn't be surprised to learn that BDB is slower than whatever
proprietary DB perforce is using.

> * Retrieving new files from Perforce is significantly faster than
> Subversion.

The svn client must 'walk' the entire working copy in order to report
its state to the server. Perforce doesn't need to do this.

> * Branching files is significantly faster than Subversion. This
> operation will happen far less frequently, though, but still takes a
> long, long time.

Try creating a branch server-side:

   svn cp URL1 URL2

instead of client side (as you did):

   svn cp wc-path1 wc-path2
   svn commit

I think you'll see a near-instantaneous result.

> * Merging files across branches is way faster in Perforce. I've been
> benchmarking this, and the merge and commit is just a few seconds in
> Perforce for a small number of files. The merge itself in Subversion is
> very quick, but EVERY time I commit, it takes OVER 30 seconds (that's
> when I quit looking at the clock and just hope it will finish).

'svn merge' is receiving diffs from the server, and applying them to
the working copy. The slowness you're seeing is in the commit, as you
say.

Just as with updates, it takes 30 seconds for svn to commit, because
it must 'walk' over the entire working copy, searching for changed
files. Perforce doesn't need to do this.

> * From an administration standpoint, server disk space is far less in
> Perforce.

Again, this is just a matter of Berkeley DB. Not a surprise that
a BDB database is bigger than a perforce DB. Someday svn will be
using any number of SQL back-ends... they'll probably be even bigger.
:-)

> Even worse, I did some benchmarks with CVS (and how I hate
> that software) earlier today (at the request of a CVS user), and CVS was
> WAY faster than Subversion, too.

Honestly, Joshua, these are the benchmarks we care most about. At
this time, Subversion's goal is to replace CVS... *not* to be
explicitly better than Perforce, Bitkeeper, Clearcase, etc.

If you repeat your tests comparing CVS and SVN, we'd be very
interested. It would be even better if you can run your tests with a
network separating the client from the repository.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 28 19:53:32 2002