On 11/3/05, Julian Foad <email@example.com> 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.
> The other thing I found was a libapr tutorial which recommends requesting
> buffered mode in most cases.
> So, conflicting thoughts.
From the apr dev list (recently)
APR doesn't seem to currently offer a buffered stdin/stdout/stderr. (Or
am I missing something?)
Unfortunately the lack of a buffered stdin is killing an application I'm
porting to APR (httpd's support/logresolve.c).
The attached patch implements some;
Colm MacCárthaigh Public Key: firstname.lastname@example.org
Which suggests to me that buffers may make a big difference. I'd need
to time a patched test-suite run to be sure though...
> One place it is probably not appropriate is when reading or writing a whole
> file at once.
Received on Thu Nov 3 15:41:09 2005