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

Re: Subversion 1.9.0-dev FSFS performance tests

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 15 Jul 2014 23:54:47 +0200

On Mon, Jul 7, 2014 at 8:59 PM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 07.07.2014 20:44, Stefan Fuhrmann wrote:
>> ... it makes SVN parse the
>> whole 64k block that the OS provides anyway ...
> [off-topic]
> See, this is the kind of statement that makes me uneasy. You make an
> assertion about "the OS" (or about "the CPU" or "the architecture") as
> if it were generally true for any OS, or CPU, or architecture; even when
> it's clear that this is simply not the case. And your implementation
> typically presupposes these generalizations.

Well, the feature is opt-in to begin with and the block size can be
configured per repository. So, there is nothing that relies 64kB being
a magic number with the guts of the OS. Having fewer fopen() and
read() operations should also always be more efficient.

Things become particularly efficient, however, if requesting larger blocks
is actually not an overhead at all - and that is the case with many device
drivers, RAID controller or OS read-ahead settings etc. (64..256kB).
It is just a little bit of extra benefit, I'd like to tap (it's also why we use
aligned reads now where feasible) but it's in no way a precondition for
the "block-read" feature to be efficient.

-- Stefan^2.
Received on 2014-07-15 23:55:17 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.