> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: donderdag 14 april 2011 23:23
> To: Neels Hofmeyr
> Cc: dev
> Subject: Re: [svnbench] Revision: 1091976 compiled Apr 14 2011, 00:21:28
>
> 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, ...
Most of my recent performance improvements were the result of profiling
Subversion on Windows 7 / NTFS (ramdrive and harddisk scenarios). Looking at
the results a I don't expect a real performance regression here:)
But please provide more numbers. We can't run on all configurations
ourselves...
The move to a single database reduced the number of differences between
operating systems.
On Windows just removing that lock problem you mentioned makes such a huge
difference that comparing performance in extremely large working copy
scenarios won't produce usable results. (1.7 is orders faster when you would
have seen that problem before)
Other changes in 1.7 should improve performance more in real world cases,
than you would see in our test runs.
With 1.6 (and earlier) updating a working copy with tree conflicts most
likely created a mixed revision working copy, which would slow down the next
update (while dropping the result). With 1.7 the update will just complete
so the next update (after you resolved the conflicts) can use the most
efficient update mode.
Another performance aspect that is very hard to test is a hot-cache vs
cold-cache scenario. With 1.7 your disk cache will usually just proactively
cache the entire SQLite database whenever you access it, while 1.6 had to
gather all the entries and properties files. I see a huge (positive)
difference here, for large working copies.
Using NFS and CIFS for working copies was never a primary use case, but all
the extreme cases reported earlier have been resolved and I expect that most
of the recent performance improvements had even more effect on these network
filesystems than on local disks.
But in this area I would love to see some real numbers.
(I would assume that network disks are usually in the same category as the
huge-working copy+cold-cache local scenarios as the local disk cache can't
cache all data)
> 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).
Bert
Received on 2011-04-15 10:22:51 CEST