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

Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 14 Apr 2011 23:22:33 +0200

On Thu, Apr 14, 2011 at 3:33 PM, Neels Hofmeyr <neels_at_elego.de> wrote:
> Hi all,
>
> yesterday's and today's benchmarks look particularly good (listed
> below). I haven't paid attention to commits, but it seems some pretty
> good perf commits have happened recently (except for 'svn delete').

> All in all, once we clarified why 'svn delete' is as slow (and possibly
> choose not to worry about it), I'd suggest that trunk's performance is
> release worthy when compared to 1.6.x.

Hi Neels,

Great work, and good to see those numbers. But ... hold on a minute
before jumping to conclusions. IIUC you only tested one type of
platform: *nix with local disk (on a (powerful) VM, and on a (slightly
less powerful) "real machine"). It gives a good indication, but it's
definitely not enough to declare trunk release worthy
performance-wise.

For all we know there could be a massive regression on Windows or
MacOS, or on NTFS specifically (like the locking in WC-1, which was
orders of magnitude slower on Windows/NTFS than on Linux), or, as
already hinted a few times by Philip, on network-mounted filesystems:
NFS, CIFS, ...

So, to get a better picture, your test-suite should be run on a
variety of platforms (others can help, I guess, like with Mark's
perf-tests). Can your test-suite be run "as is" by others on Windows
for example? Maybe you could already run it yourself on an NFS-mounted
volume?

I think we need to at least test [ *nix | Windows | MacOS ] x [ local
disk | remote disk ] (ok maybe *nix is too coarse-grained, as is local
disk etc..., but you get the picture).

Cheers,

-- 
Johan
Received on 2011-04-14 23:23:24 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.