[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Missing APR_BUFFERED flag on file open?

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2005-11-04 09:52:59 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.