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

Re: [RFC] A libsvn_wc properties optimisation (NFS timing stats)

From: Bill Soudan <bill_at_soudan.net>
Date: 2004-11-12 14:33:08 CET

On Sat, 6 Nov 2004, Philip Martin wrote:

> At present each versioned file has two properties files in the admin
> area, the base properties and the working properties. Files that
> don't have properties use empty properties files, ones that just
> contain END.
> I propose to remove both properties files for items that don't have
> properties. Further, for items that do have properties but don't have
> property modifications I propose to remove the working properties
> file. When there is no working properties file it should be possible
> to remove prop-time from the entries file, making it slightly smaller
> and faster to parse.
> This will the following effects, it will reduce the disk space used by
> lots of working copies (possibly 2500 files for a Subversion trunk,
> which is 10MB if each file uses a 4KB block or 15% of the total), it
> will reduce disk IO when checking out a working copy, and it will make
> detection of property changes more efficient.

I think this will be a big win for NFS mounted working copies as well.
This was a while ago, but for some timing stats, check the following


I suppose they could be different on the latest version of Subversion. I
am planning on upgrading to 1.1.x in the next month or two, if desired,
once we upgrade I would be happy to gather new data.

Basically, the wcprop manipulations during switch were a HUGE drain,
accounting for ~259s of the ~277s during a svn switch. At the time, Karl
suggested I switch to the svn:// access method, which doesn't require
wcprops, which is what we use to this day. But the amount of wcprop
manipulation during my test just destroyed the performance over an NFS
mounted home dir.

This may also indicate combining the wcprops into a single file per
directory (like entries) would be a good thing, as well, which was
suggested previously in this thread.

If this overhead could be eliminated, it would make http:// a viable
option for us, which would be nice.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 12 14:33:35 2004

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.