On Mon, Jul 7, 2014 at 8:59 PM, Branko Čibej <br...@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.
