RE: Apparent "svn rm" scaling problem in 1.7.x

Benchmarking with 49 files is taking too long. Here are some benchmarks of trying to delete a directory with 5 files. I am using approximations because I am seeing variations in each run due to network traffic.

"svn rm dir/*" 1.6.17 ~0.15s
"svn rm dir" 1.7.1 ~10s
"svn rm dir/*" 1.7.1 ~50s
"svn rm dir/*" 1.7.1.p1 ~30s (single transaction)
"svn rm dir/*" 1.7.1.p2 ~25s (sqlite change)
"svn rm dir/*" 1.7.1.p3 ~30s (c code change)

We can continue to benchmark deletes on multiple files, but I still think the culprit is the fundamental svn rm command is too slow.

-----Original Message-----
From: Stefan Sperling [mailto:stsp_at_elego.de]
Sent: Tuesday, November 01, 2011 12:30 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); users_at_subversion.apache.org
Subject: Re: Apparent "svn rm" scaling problem in 1.7.x

On Tue, Nov 01, 2011 at 07:00:57PM +0100, Stefan Sperling wrote:
> On Tue, Nov 01, 2011 at 11:31:35AM -0600, michael_rytting_at_agilent.com wrote:
> > It's just one directory that has 49 files in it.
>
> Good. Please try this patch in addition to the other one.
> It makes 'svn rm dir/*' with 49 files go down from about 4.20 seconds
> to about 1.50 seconds for me (local disk).
>
> Note that I am not going to commit this as is.
> It just tests whether the overhead of sorting paths in sqlite matters
> much on NFS.

I went ahead and implemented sorting the deleted items list in C.
The following gives you a patch that applies cleanly on top of my previous 1.7.x patch:

 svn diff -c1196191 https://svn.apache.org/repos/asf/subversion/trunk

Can you try that? Thanks.
Received on 2011-11-01 20:46:27 CET