NFS performance regression in 1.9

There is a performance regression for checkout on NFS with 1.9. I'm
using 1.7.x as my dataset, a 95MB checkout, with localhost as my
Subversion server, so NFS is almost the only network traffic. I'm
comparing 1.7 patched to enable exclusive locking, with 1.8 and 1.9 both
with exclusive locking enabled:

  1.7: 73s
  1.8: 66s
  1.9: 90s

For comparison a local checkout is less than 2s. I've tried both
http:// and svn:// and get similar results.

So 1.8 is better than patched 1.7 but 1.9 is much slower than both.

Using "strace -c" I can see 1.9 generally makes slightly fewer system
calls apart from chmod() and ftruncate(). The extra chmod() calls are a
result of a new feature in 1.9: the pristine text-bases are read-only.
The ftruncate() calls are due to r1659426:

  Use journal_mode = TRUNCATE for sqlite [1] instead of default DELETE value.
  It makes svn checkout about 10% faster on Windows at expense of one empty
  file in .svn. Create/delete file is relatively expensive operation on
  Windows, especially if indexes/virus scanners are enabled.

These two changes explain the 1.9 regression, if I patch them back then
1.9 is as good as, or better than, 1.8.

We can't fix the chmod() problem: the new feature has a cost. We also
don't want to give up a 10% Windows gain. The TRUNCATE change is the
one that has the biggest effect on NFS performance so I propose to
continue with TRUNCATE as default but have exclusive locking mode switch
back to DELETE:

Index: ../src-1.9/subversion/libsvn_wc/wc-queries.sql
===================================================================
--- ../src-1.9/subversion/libsvn_wc/wc-queries.sql (revision 1708752)
+++ ../src-1.9/subversion/libsvn_wc/wc-queries.sql (working copy)
@@ -1286,7 +1286,8 @@
    OR (wc_id = ?1 AND IS_STRICT_DESCENDANT_OF(local_relpath, ?2))
 
 -- STMT_PRAGMA_LOCKING_MODE
-PRAGMA locking_mode = exclusive
+PRAGMA locking_mode = exclusive;
+PRAGMA journal_mode = DELETE
 
 /* ------------------------------------------------------------------------- */
 
This change brings the 1.9 checkout time down to 69s, so only 5% slower
than 1.8 rather than 36%.

-- 
Philip Martin
WANdisco