[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 25 Jun 2012 10:32:53 -0400

On Mon, Jun 25, 2012 at 10:31 AM, Bert Huijben <bert_at_qqmail.nl> wrote:

>> Attila Nagy <bra_at_fsn.hu> writes:
>>
>> > I suffer from the slowness of svn rm since the upgrade to 1.7 from
>> > 1.6, but I couldn't find the time to profile it until now.
>> > My setup is: FreeBSD 9-STABLE/amd64 with zfs, eight fast cores, SAN,
>> > 32 GiB of RAM.
>> > Versions:
>> > svn, version 1.7.5 (r1336830)
>> > sqlite: 3.7.12.1 2012-05-22 02:45:53
>> > 6d326d44fd1d626aae0e8456e5fa2049f1ce0789
>>
>> > Any ideas about how could it be made even faster without ditching
>> > sqlite? Deleting 100 files and committing the change shouldn't take 40
>> > (10, with the above indexes) minutes, even with 2 million files... I
>> > guess.
>>
>> SUbversion 1.8 (trunk) has various speed improvements to the working
>> copy library.  Is your working copy on the SAN?  Depending on how the
>> SAN works you may find that the exclusive locking patch in issue 4176
>> helps: http://subversion.tigris.org/issues/show_bug.cgi?id=4176
>
> This sounds like the scalability problem that was fixed by upgrading Sqlite
> 3.7.9 or later.
> (Without that we perform a full table scan, which in this case would be 2
> million times (the number of nodes) slower than deleting with the proper
> index usage)

He said he is using 3.7.12.1

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-06-25 16:33:24 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.