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

Re: svn commit: r1022931 - in /subversion/trunk/subversion/libsvn_wc: status.c wc-queries.sql wc_db.c wc_db.h

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 20 Oct 2010 12:04:58 +0100

Johan Corveleyn <jcorvel_at_gmail.com> writes:

[about status performance]

> On my machine (WinXP, 32 bit, local disk 5400 rpm), with a medium size
> working copy (944 dirs, 10286 files; same as I used in previous tests
> ([1])):
>
> - cold cache: 1.7 is almost 50% faster than 1.6
> 1.7: 22s
> 1.6: 42s
>
> - hot cache: 1.7 is just about on par with 1.6 (only 20% slower)
> 1.7: 0.86s
> 1.6: 0.72s

So 1.7 is more of an advantage on Windows than Linux. That's no bad
thing since Subversion has historically been slow on Windows.

The performance with working copies on network disks is more of a
concern. I'm tried working copies mounted via NFS and Samba (I'm
using Linux for client and server). In both cases 1.7 is slower than
1.6

- using NFS
1.6: 1.4s
1.7: 9.0s

- using Samba
1.6: 2.5s
1.7: 4.4s

NFS on my system does some caching so a second call to status is
significantly faster:

- using NFS repeatedly
1.6: 0.4s
1.7: 8.0s

So NFS is a real concern, it's an order of magnitude slower. If I
hack the client to run the whole status within a savepoint, to make it
a single transaction, the 1.7 performance improves:

- using NFS
1.6: 1.4s
1.7: 1.5s

- using Samba
1.6: 2.5s
1.7: 1.7s

- using NFS repeatedly
1.6: 0.4s
1.7: 0.5s

Properly implementing status as a single transaction is not simple.
We either need to expose the SQLite savepoint interface to the
libsvn_wc code, or change the per-dir implementation into a per-tree
one.

-- 
Philip
Received on 2010-10-20 13:05:43 CEST

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