Ryan Bloom wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
"Ryan Bloom" <[EMAIL PROTECTED]> writes:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
"Ryan Bloom" <[EMAIL PROTECTED]> writes:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
A little bird told me that FD_ZERO() burns lots of cycles in
apr_wait_for_io_or_timeout(). It turns out that this is an
easy
conversion to poll(), which doesn't have such overhead in the
interface.
This works for me with some testing (timeouts on read and
write
work
for me).
Can we remove the #ifdef's by just using apr_poll here?
I'd rather we not, since that introduces a fair amount of extra
overhead.
Then let's get rid of the overhead.
redesign the API
The redesign the API, but FIX the performance problem!
If we don't use apr_poll,
then
the
overhead is maintenance,
the marginal extra maintenance is certainly something I can live with
here... this is an important path within APR... if we can use the
most efficient mechanism without much extra maintenance then we
should...
You are missing the point. If apr_poll() is to be useful to external
projects, then it must perform well. If it performs so poorly that we
refuse to use it inside of APR, then it couldn't possibly be useful to
external projects. That is straight-line reasoning in my mind.
My concern is that you're obscuring a fundamental point: different
applications have different performance needs. Sometimes a lightweight
library function performs adequately for the target application.
Sometimes you have to inline to implementation because you're using
it in code where speed is more critical. In order to make apr_poll()
suitable for *all* applications, from a performance perspective, we'd
have to turn the entire function into a macro so it can be inlined.
But that's a bad idea for a lot of other reasons, so we leave it a
function so that it meets the needs of 99% of the code that might
want to use it. The other 1%, the 1% with the most extreme performance
concerns, will always need a custom solution. That's no different from
our use of libc: we try to use a function in the public API if it's
helpful to do so, but we write an inline equivalent in cases where
we need the highest possible speed or specialized semantics.
Why in the world would we leave an API in APR that performs so poorly
that we refuse to use it in our own library? Doing that boggles my
mind.
We've made no promise to users of APR that APR functions will be
implemented as calls to other APR functions, and IMHO it wouldn't be
helpful to users if we ever did so. The promise that APR makes to
its users should be: "each function in this library's public API
is as well-tuned as we can make it." That's much more useful to
a customer of the library than a promise "each function in this
library is implemented via calls to other functions in this library."
--Brian
