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