On Mon, Dec 6, 2010 at 8: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.
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
Received on 2010-12-09 18:04:29 CET