Julian Foad wrote:
> Erik Huelsmann wrote:
>
>> It looks like we use a lot of non-buffered file i/o:
>>
>> Seaching for '(APR_READ or APR_WRITE) and not APR_BUFFERED' returns 31
>> files, whereas '(APR_READ or APR_WRITE) and APR_BUFFERED' only returns
>> 7.
>>
>> Is it intentional that we haven't specified APR_BUFFERED so often?
>
>
> Hmm. What exactly is the benefit of this flag? Looking at the code,
> I see it causes APR to do its own buffering on top of what the C
> run-time library and/or OS already do. This presumably allows greater
> read/write efficiency (depending on the size of the transfers) at the
> cost of a time and memory overhead on the initial access.
>
> Does that balance out in our favour? I would expect an API to be
> designed so that it works best for the usual cases without any extra
> options being specified, which would imply that the buffered mode is
> only appropriate for some special cases, but that might not be so.
>
> Searching the web, I found an email discussion in 2000 questioning
> whether the buffering code is really wanted. Apache had httpd stopped
> using it, which casts doubt on its value.
> <http://mail-archives.apache.org/mod_mbox/httpd-dev/200004.mbox/%3cPine.LNX.4.10.10004031444170.19464-100000@nebula.lyra.org%3e>
>
>
> The other thing I found was a libapr tutorial which recommends
> requesting buffered mode in most cases.
> <http://dev.ariel-networks.com/apr/apr-tutorial/html/apr-tutorial-5.html>
>
> So, conflicting thoughts.
>
This depends alot on the underlying OS and hardware. If all of your
local destination buffers are aligned to match the I/O read required
alignment (depending on your platform / hardware / drivers, this could
32 bytes, 128 bytes, 4KB, 24KB, 32KB, 128KB etc..).
If you are using non-buffered I/O to read into unaligned address, then
you could be causing lots of extra data to be transferred and thrown
away when ever a file I/O request happens. On the other hand, if all of
your destination buffers are aligned to the platform / OS requirements,
then using non-buffered I/O can protect against L1 / L2 cache misses
caused by data re-copies from the internal read buffers.
Of course if APR's internal read buffers aren't aligned to the correct
values for your OS / hardware, then they are worse than useless and
probably hurting performance in the long run.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 4 09:59:39 2005