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. 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
Received on 2010-12-07 05:31:10 CET