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

Re: performance on cygwin

From: Matthew Bentham <mjb67_at_artvps.com>
Date: Wed, 10 Feb 2010 12:47:06 +0000

stsp_at_stsp.name wrote:
> On Wed, Feb 10, 2010 at 11:57:35AM +0000, Matthew Bentham wrote:
>> 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 :)

OK! I'll track changes for now, and I'm here if anyone wants me to try
out something specific.

> 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, somehow I missed that thread when reading the archives before

Just for fun I tried building with "PRAGMA journal_mode=MEMORY", the
result is:

$ time /cygdrive/e/subversions/subversion/profinstalldir/bin/svn.exe update
At revision 36896.

real 0m17.685s
user 0m6.000s
sys 0m7.109s

 From my original post, running subversion 1.6:

> $ time svn update
> At revision 36888.
> real 0m19.865s
> user 0m0.250s
> sys 0m1.468s
> $

Which I think is pretty conclusive evidence (if any more were needed)
that the performance problems will be solved by reducing the database IO

All the best,
Received on 2010-02-10 13:47:46 CET

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