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

Re: svn client performance..

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-03-02 00:02:49 CET

Josh Siegel <joshs@stormbirds.org> writes:

> The "subject" of the test was a directory that
> contained 3 files. I had already checked the files out so all I was
> doing was calling "svn up scripts" which was not actually doing
> anything.

> The key things to notice are the calls to open() where it is changing
> files and rename(). It looks like it rewrites the entries file 3
> times for each directory plus the dir-wcprops once.

The first write adds 'incomplete="true"', the second makes changes due
to the update, the third removes 'incomplete="true"'.

There does appear to be a "bug" in that the changes aren't really
changes, they involve setting properties such as last-author that
aren't changing. The entries caching really ought to eliminate such
"fake" writes.

Aside from that, there are a number of optimisations that I haven't
implemented them yet:

1/ We might be able to avoid adding 'incomplete="true"' if the
   directory revision is not changing.

2/ We might be able to cache 'incomplete="true"' in the access baton
   and only write it when first modifying the entries file.

3/ It might be possible to combine the removal of 'incomplete="true"',
   and the bumping of the revision number, with the last change due to
   the update.

> Translated to a real world example, my build environment has 1272
> directories. This means that to do a "svn up" at the top requires my
> client to write 3816 unchanged copies of entries and then call rename
> 3816 times to replace the previous version.

I don't think it's that bad. If there are no changes then the update
won't recurse into any of the sub-directories. An update that only
changes the revision will only write each sub-directory entry file

> Of course, it is also
> rewrites dir-wcprops 1272 times with no changes. Ie, we have more
> then 5000 file-creations and 5000 file-renames having no effect

Ideally we would not write the file if it does not change, but at
present the value is not cached in memory so to do that would involve
reading the file first. I'm not sure that's an improvement. If you
use svn:// it it doesn't set wcprops.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 2 00:04:00 2005

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.