On Mon, Dec 6, 2010 at 8:01 PM, Blair Zajac <bl...@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.
This feels really bizarre. Isn't checkout just "create an incomplete directory, then update it"? As such, one would think the performance would be comparable. Bizarre indeed.... -Hyrum
