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.
One place it is probably not appropriate is when reading or writing a whole
file at once.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 15:21:25 2005