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

RE: svn ci performance issue with 1.7.x and nfs mounted working copies

From: <michael_rytting_at_agilent.com>
Date: Wed, 14 Dec 2011 17:37:11 -0700

Just as a comparison, the same operation with the same working copy takes 2s in subversion 1.6.17 vs 1m11s in 1.7.2. This is a pretty big deal for us.

-----Original Message-----
From: Peter Samuelson [mailto:peter_at_p12n.org]
Sent: Wednesday, December 14, 2011 4:48 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); dev_at_subversion.apache.org
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies

[Philip Martin]
> That will be because commit does one or more SQLite transactions
> per-node, while status has been optimised to do fewer per-directory
> transactions. The number of SQLite transactions is what dominates
> Subversion working copy performance on network disks. By running
> commit on a subtree you are restricting the number of nodes commit has
> to process and that reduces the number of SQLite transactions.

This would imply that the other way to get faster commits is to specify your filenames explicitly, instead of using the default of "any changed item under the current directory".

If this rather dramatic speed difference between 'status' and 'commit'
is really a common case, it's probably worth reimplementing 'commit' in terms of the same thing 'status' does. But I'm not deep enough in the wcng code to know if that's a reasonable course.

--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-12-15 01:37:48 CET

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

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