Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <rbb@covalent.net>
From: "Ryan Bloom" <rbb@covalent.net>
To: "'Brian Pane'" <brianp@apache.org>,
	<dev@apr.apache.org>
Subject: RE: [PATCH] speed up network timeout processing
Date: Wed, 3 Jul 2002 09:12:53 -0700
Organization: Covalent Technologies
Message-ID: <00d101c222ac$7c995ca0$5000000a@KOJ>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3D2320BA.6080907@apache.org>
Importance: Normal

> From: Brian Pane [mailto:brianp@apache.org]
> 
> Ryan Bloom wrote:
> 
> >>From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> >>
> >>"Ryan Bloom" <rbb@covalent.net> writes:
> >>
> >>
> >>
> >>>>From: trawick@rdu88-250-182.nc.rr.com [mailto:trawick@rdu88-250-
> >>>>
> >>>>"Ryan Bloom" <rbb@covalent.net> writes:
> >>>>
> >>>>
> >>>>
> >>>>>>From: trawick@rdu88-250-182.nc.rr.com
> >>>>>>
> >>>>>>
> >[mailto:trawick@rdu88-250-
> >
> >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.

But the whole point of poll() is that it performs better than select.
That is the only reason the poll() API was ever created.  If apr_poll()
doesn't meet that need, then we have a major problem.  Add to it that
the performance problems with apr_poll() have been brought up on this
list before, and I believe you have a compelling reason to fix the
function.

This all comes down to eating our own dog food, which does multiple
things.  1)  It helps us ensure optimal performance and 2)  it helps us
find bugs.

> 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.

I still have the question, have we even tried profiling with
apr_poll????  If the answer is no, then we are falling into the common
trap of assuming poor performance without any real numbers.  If yes,
then let's look at the implementation of apr_poll and see where the
problems really lie and if they are fixable.

> >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."

We have made the promise that using APR will not seriously impact the
performance of your app when compared to not using it.  If apr_poll() is
so poor from a performance viewpoint that it has major overhead when
compared to poll(), then we haven't met that promise.

Ryan