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

Re: Performance benchmarks

From: Daniel Becroft <djcbecroft_at_gmail.com>
Date: Tue, 29 Mar 2011 19:54:57 +1000

On Sun, Mar 27, 2011 at 4:51 AM, Mark Phippard <markphip_at_gmail.com> wrote:

> On Fri, Mar 25, 2011 at 1:33 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> > I have been working on a framework for writing tests to record
> > performance. I have something good enough to share:
> >
> > https://ctf.open.collab.net/sf/projects/csvn
> >
> > It is pretty easy to add new tests if you have ideas on more tests you
> > think we should add. I think I have pretty good coverage of the major
> > functions. The wiki on the site I linked to above has details on how
> > I have constructed the current tests. I am going to put out a call to
> > users for feedback and try to get more people to run the tests and
> > record results.
> >
> > I am not claiming these are anything definitive or even that we will
> > use them to help us make the release decision, but I think it is a
> > start on coming up with some reproducible tests that people can run
> > easily. If after people look at and run the tests they think they are
> > useful or can be tweaked to be useful, then great. If not, then at
> > least I got to write some code for a change :)
> >
> > The tests are written in Java because that is what I know and it gives
> > me good cross platform coverage. However, the Java just drives the
> > command line so all you need to do is have the svn command line in
> > your PATH and that is what it uses for all the work.
> These tests are showing some interesting results.
> * There are a number of cases where 1.7 shows large performance gains
> over 1.6. For example, a WC with a lot of folders on Windows:
> https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/FolderTests
> * Checkout seems to be the biggest remaining hotspot where 1.7 tends
> to be slower, although commit seems to still be slower too.
> * Delete and move are slower than I would have expected. Is this
> because we can actually delete the folder now, as opposed to waiting
> until commit time? I actually thought that made would make it faster
> as I thought the folder used to get deleted and then put back (maybe
> just in IDE's).
> * There is something seriously bad going on with Anti-Virus on my
> Windows laptop (Symantec Endpoint Protection). I noticed the times
> for commit were way out of whack so I configured my A/V to ignore the
> folder where the benchmarks were running. When I ran the tests again,
> the performance of 1.7 was waaay better. I am about 95% certain the
> A/V is the problem but I need to make sure. While it was great to see
> the good performance, it is still a big concern to see that A/V might
> be having an even bigger impact than it has before. 1.6 also showed
> performance improvements but they were less dramatic than some of the
> 1.7 commands.
> Stefan Küng asked me to add svnversion to the benchmark and I have
> done so in the latest release.
> I would love to see someone do some tests with the WC on local disk vs
> network mount (1.6 and 1.7). I tried to do it using some virtual
> machines I have access to at CollabNet. The problem is that the
> connection of these boxes to the NetApp with our home folders is too
> slow. Some of the checkouts (even using 1.6) were running for an hour
> and I finally killed the test.
> Anyway, overall I am encouraged by the results I am seeing so far. I
> look forward to more people running the tests and sharing the results.
Attached are my results from the benchmark suite. I've provided two versions
of the 1.7.0 run. One was an older build (prior to the optimizations), and
the last one was a recent build.

These were all run over file:///. I'll try and see if I can re-run it over

Daniel B.

Received on 2011-03-29 11:55:52 CEST

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.