Paul Burba <ptbu...@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. 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
