> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: maandag 25 juni 2012 15:05
> To: Attila Nagy
> Cc: users@subversion.apache.org
> Subject: Re: svn rm much slower on 1.7.5 than on 1.6 (with SQL timings)
>
> Attila Nagy <b...@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)
Bert
>
> --
> Philip
