On Wed, Feb 10, 2010 at 11:57:35AM +0000, Matthew Bentham wrote:
> Hi,
>
> The summary is that I'm motivated to help with work on the
> performance of Windows subversion clients, because the speed of 'svn
> update' is not great for us on large working copies, and we keep
> having to re-arrange our source to work around that.
>
> At work I've used Subversion happily for many years. There are
> perennial discussions in the office about the performance of the
> windows clients. Several times in the past we have had to carefully
> prune the project, especially external modules imported into our
> code, in order to keep acceptable performance of 'svn update'. The
> Linux clients have always been fine.
>
> I've been hearing rumours of performance improvements to Windows svn
> clients with the 'wc-ng' work. A couple of weeks ago I decided to
> have a go with subversion trunk to see what it would make of our
> repository. I've compiled it, compared the performance with
> subversion 1.6 from cygwin, and done some profiling with Intel
> VTune. The results follow, I hope they are interesting.
Thanks for profiling the code. This is quite interesting and
I think the results are in line with our expectations.
We're aware that trunk is currently slower than 1.6.x.
The major reason for the current performance problems in trunk is that
the .svn directories have not been centralised yet. Once there is only
a single .svn directory at the root of the working copy, we expect a
large speed-up since only a single sqlite database will be used.
It would be great if you could profile the code again once we have
reached that goal. If you want to help us reach that goal faster,
please join the wc-ng development efffort :)
The current non-performance of trunk has been discussed before,
e.g. see http://svn.haxx.se/dev/archive-2009-09/0189.shtml
and related messages.
Thanks,
Stefan
Received on 2010-02-10 13:23:07 CET