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

Re: Performance issues versus CVS

From: Brandon Ehle <behle_at_hypnos-entertainment.com>
Date: 2004-04-17 05:13:28 CEST

Ben Collins-Sussman wrote:

>On Fri, 2004-04-16 at 02:28, Brandon Ehle wrote:
>
>
>
>>I last ran my perf suite in Oct 2003 (I think right after a major
>>performance enhancement had been committed) and my results were similar.
>>
>>
>
>Actually, our big "speed enhancements" came out with svn 0.33, November
>13th. So I'd be curious to see how 1.0.1 performs in your tests today.
>
>
>
>
Here is the new results fresh off the press:

http://subversion.kicks-ass.org/perfnew/elapsed.html
http://subversion.kicks-ass.org/perfnew/maxresident.html
http://subversion.kicks-ass.org/perfnew/

And I've got a link to the old results for comparison purposes:

http://subversion.kicks-ass.org/perf/elapsed.html
http://subversion.kicks-ass.org/perf/maxresident.html
http://subversion.kicks-ass.org/perf/

There does seem to be a big performance improvement in the DAV access
method. Checkouts on the whole are slightly more scalable, but the base
cost seems to be about the same, but other than that ra_dav and ra_local
performance looks almost identical

Memory usage appears to be slightly better for import, and slightly
worse for checkouts. There appears to be a huge improvement in the
memory usage during an emptyupdate ("svn up" when there are no new files
on the server), but it didn't seem to affect runtime performance.

I've also added a perf test for the "svnserve -T" threads option, but it
looks identical to the performance of the fork method (unless of course
I've screwed something up in the test).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 17 06:43:35 2004

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

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