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

Re: the New Checkout System

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2003-05-21 03:25:13 CEST

>The bad news: for both of our network layers, this new system slows
>down checkouts by ~35%. I did a bunch of timings, checking out
>subversion's own /trunk directory via http://localhost,
>svn://localhost, and file:///. For http: and svn:, the new system
>took about 35% longer. For file:, the new system was *faster* by
>about 35%. Crazy.
>
>I don't know what to think... or whether to apply the patch. I'll
>attach it to this mail and lets others examine it, analyze it, etc.
>
>

I ran your patch through a bunch of performance tests and I've found
that your patch seems to make files checkout slower, and directories
checkout faster.

First off, I see radically different results over ra_local depending on
what priority the svn process is running at. With sussman's patch if I
run svn at normal priority, I see a 30-50% slowdown. With a -10
priority, the slowdown is only around 5-10% (vs the non-patched version
running with a -10 priority as well). This is probably a seperate issue
unrelated to Sussman's patch and I'll be looking into this more thoroughly.

For the rest of the results, assume all server and client processes are
running at -10 priority. Also, these results are for high-speed
connections, for low-speed connections, the results might be radically
different.

For a single directory with lots of files, I see a 5-10% slowdown across
the board (ra_local, ra_svn & ra_dav). But with a repository containing
a small amount of files spread among several directories (~10 files per
directory), I see around a 10-15% perfomance boost across all three
access methods. From what I've seen of most repositories, your patch
should result in a slight performance boost on the average.

 From what I've seen, there is no reason to not commit the patch. At
the very least, it means that there is less code to deal with when
someone does get around to optimizing updates & checkouts.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 06:24:56 2003

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.