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

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