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

Re: 1.7 timing tests: update great, checkout needs work, upgrade horrible

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Tue, 7 Dec 2010 14:30:17 +1000

 On Tue, Dec 7, 2010 at 2:01 PM, Blair Zajac <blair_at_orcaware.com> wrote:

> I'm working with a client and they have a large source source code checkout
> that takes over 10 minutes do to an svn update. Their 1.6.x working copy
> size is 3.6 GB with 74,000 files and 19,230 directories. The amount of IO
> to do all the locking and reading entries files is taking a significant
> amount of time.
> They are looking at techniques to speed up updates, as it's a significant
> productivity drain, but it's much slower than git-svn.
> So we thought we'd try the 1.7 client at r1042760.
> The good news is that "svn update" is significantly faster than 1.6,
> dropping from over 10 minutes to 3:07 with a cold cache and 0:48 with a warm
> cache. This is great.
> Unfortunately, it looks like checkout times have gotten worse. On a SATA
> disk with ext3:
> Clock System User
> time time time
> 1.6 5:41 94.1 58.9
> 1.7 12:20 106.2 99.9
> I noticed that doing an strace of the checkout leads to a 1.3 GB file with
> 1.6.x and 4.1 GB with 1.7.x, so many more operations.
> I haven't been following 1.7 performance lately, but are we aware of this?
> Are there any obvious performance fixes here?
> I realize that 1.7 is a ways away, but the scalability svn update brings to
> svn checkouts is a significant win.
> We also tried an 1.6.x checkout followed by a 1.7 upgrade. Last I looked
> the process it had 110 minutes of CPU time. Definitely not worth upgrading,
> faster to do a fresh checkout, even with the checkout performance slower
> than 1.6.x.

I've found the same problem during my testing[1]. I've only recently built
my own version of 1.7.x under ubuntu, and haven't had a chance to retest the
upgrade with this build. On Windows, I found that after a period of time,
the upgrade process would start reading the entire wc.db file continuously.
This was when the file started to get up around the 4Mb mark. I'm not sure
if it's a sqlite problem, or a table scan issue with a query, or some other

Daniel B.

[1] http://svn.haxx.se/dev/archive-2010-11/0503.shtml
Received on 2010-12-07 05:31:10 CET

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.