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

On Fri, Apr 15, 2011 at 10:22 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----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:)

Great

> But please provide more numbers. We can't run on all configurations
> ourselves...

I have (with Mark's benchmarks), and I will continue to do so (was
thinking of running Mark's benchmarks with a CIFS-mounted working
copy). If Neels' benchmarks also work on Windows, I'll try running
them too. But honestly, I also don't have much tuits to spare
currently, so don't expect too much on the short term.

OTOH: maybe you're speaking to the mailinglist-public in general, not
just to me :).

> 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.

That all sounds great.

To be honest: I don't expect much platform-specific performance
regressions either (at least not with local disks), because there is
so much testing/developing/profiling going on on Windows now. But I
was more speaking out of principle: don't assume it's performant on
all platforms just because it's performant on one single flavor.
That's exactly the attitude that makes it possible to miss huge
platform-specific performance problems like with the WC-1 locking
code.

Luckily, there seems to be a good amount of attention to usage on
Windows these days, and devs working/focusing also on Windows, so I
don't expect any disasters. But still, the principle :)...

(note: I don't want to start any religious wars. Windows isn't my
favorite OS either, but I (have to) use it at work, and there happen
to be tons of svn users running Windows, so ...).

> 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)

Yes. I understand NFS/CIFS working copies are not the primary use
case, but I do think they are being used more and more often. In a lot
of corporate environments, people have homedirs on a remote fileserver
(NAS/SAN/whatever/... with snapshots, backups, failover, ...). Be it
on *nix, with NFS mounts, or on Windows, with CIFS mounts. All the
important data is supposed to be put on those volumes, so that the
data is safe, and it can be mounted from anywhere ... So I just see
this happening more and more.

Theoretically, I can see that with WC-NG things should become faster
in those situations (reducing the lots-of-small-files-I/O of the lock
files, entries file, ...). So if the extreme cases that were reported
earlier have been fixed, it should be ok. I agree it would be good to
have some more numbers here ...

Cheers,

-- 
Johan