On Tue, Jun 7, 2011 at 7:51 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Paul Burba <ptburba_at_gmail.com> writes:
>
>> I ran a series of simple comparisons today, checking out the 1.6.17
>> tag vs. upgrading a 1.6 WC of the same. The upgrade was about twice
>> as slow (yes obviously there are a lot of moving parts here and making
>> a comparison between a local operation and one over the network is
>> inherently dubious, but it's something):
>
> Upgrade can be faster or slower than checkout, it depends on what one
> measures. I am using trunk as my data set, rather than 1.6.17, and I am
> checking out from a local mirror across my LAN.
>
> Checkout with 1.6 is about 9s elapsed, 6s CPU.
> Checkout with 1.7 is about the same.
> Upgrade with 1.7 is about 4s elapsed, 4s CPU.
>
> So upgrade is clearly faster than checkout.
>
> But wait! I get the numbers above by running upgrade directly after
> checkout, which means the the 1.6 working copy is in the client
> machine's OS cache (the client is a Linux laptop with a standard,
> rotating, SATA disk). If I drop the OS cache between checkout and
> upgrade then:
>
> Upgrade with 1.7 is about 15s elapsed, 4s CPU.
Hi Philip,
Thanks for the info.
No surprise that your checkouts are faster than mine given you are
using a local mirror. What's puzzling me is why my upgrades are so
much slower than yours.
Running an upgrade of a trunk WC on my machine under xperf takes
00:03:46.351 elapsed and 11.44s CPU time using my primary drive (320
GB, SATA-II, 7200 rpm, 16 MB Cache, NTFS). Subversion spends 50s
total disk service time (46.8s of that is read service time).
I've defragmented this disk, real time virus scanning is disabled,
TSVN is currently not installed so no overhead from TSVNCache,
compression is turned off, I'm using Win 7 Home Premium so there is no
option to use encryption, content indexing is turned off,
write-caching is enabled, write-cache buffer flushing is disabled, 8.3
filename creation is turned off, and last access timestamp is
disabled.
Are any Windows users out there seeing similar performance with 'svn
upgrade' or have any suggestions for further optimizing Win 7 disk
performance?
As I detailed in my earlier response to Julian, upgrading a 2GB
working copy on my box took close to 4 hours! I'm fine if this poor
performance is simply something to do with my particular configuration
(or flaky disk), but if this is what Windows users in general have to
look forward too we might have a problem.
Paul
> Upgrade is clearly slower than checkout.
>
> In this case upgrade always uses less CPU, so it is in some sense more
> efficient, but it's not really possible to say whether it is faster or
> slower.
>
> If anyone want's to improve the upgrade code it might be worth looking
> at using transactions to combine the large number of queries used to
> migrate properties.
>
> --
> Philip
>
Received on 2011-06-13 21:30:54 CEST