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

Re: svn commit: r1139766 - /subversion/trunk/subversion/svn/main.c

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 27 Jun 2011 12:52:37 +0100

Stefan Sperling <stsp_at_elego.de> writes:

>> I disagree.
>> Upgrade requires more disk IO but requires significantly less network IO
>> and uses marginally less CPU. Checkout is likely to be faster when disk
>> IO is the limiting factor, but if network IO is the limiting factor then
>> checkout could be significantly slower.
> When I upgraded a 1.6.x working copy of 2GB size, it took more than one hour.
> I eventually just aborted the upgrade. A checkout completes within
> a couple of minutes.
> The repository is remote and the bottleneck should be my 16MB/s downstream
> link (the server is connected to my ISP via the berlin internet exchange
> at 100Mbit/s). So based on what you're saying I should be seeing a much
> better upgrade vs. checkout ratio.
> Link to the repository: http://svn.dslinux.org/svn/trunk
> svn also seemed to spend more and more time hogging the CPU as the upgrade
> progressed. Note: I have not profiled this, it is all based on what I
> perceived while waiting for the upgrade to complete, and I kept box getting
> more and more impatiant. I'd be willing to repeat this experiment with a
> profiled build.

I don't know why that upgrade is slow, but perhaps you are limited by
disk IO. Maybe upgrade doesn't scale properly.

It's wrong to claim that checkout is faster than upgrade
unconditionally. A checkout of Subversion trunk from Apache takes about
10s on my machine, an upgrade takes 5s. That's with a hot cache, with a
cold cache upgrade takes about 15s. The checkout speed varies,
sometimes it takes ove 20s. Which one is faster?

Received on 2011-06-27 13:53:13 CEST

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.