[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Performance (Subversion vs. CVS)

From: Brian W. Fitzpatrick <fitz_at_collab.net>
Date: 2004-09-14 06:12:32 CEST

On Sep 13, 2004, at 9:37 PM, Greg Ward wrote:
...

> 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

...

> 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
>
> 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?

It's not the server that's killing your timings here... it's the time
that Subversion requires to poll (and in some cases, update) the
working copy.

When you do straight-up profiling of the above operations, Subversion
comes up slower because it's got a lot more work to do (parsing xml
entries files, changing them, writing them out to disk). Oh, and
Subversion journals all working copy actions before parsing and
executing too, so that slows you down a bit as well.

However in day-to-day work, I find that I rarely checkout a new working
copy, and only switch every couple of days. But I do the following
dozens (sometimes *hundreds*) of times a day:

$ svn status
$ svn diff
$ svn commit

and less often

$ svn update
$ svn status -u

I find that the speediness of those commands really makes up for the
slowness that you noted above. That's not to say that Subversion isn't
slow and could be faster--I'd *love* to see it sped up! It would still
be great if you grabbed a profiler and dove in to see if you can help
speed Subversion up. :-)

-Fitz

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 14 06:13:14 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.