apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] speed up network timeout processing
Date Wed, 03 Jul 2002 18:39:20 GMT
> From: Brian Pane [mailto:brianp@apache.org]
> Sent: 03 July 2002 18:05

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

Could someone please profile this function and see where the problems
are?  That way we know why we wish to bypass it inside APR (or know
what to fix in apr_poll).



View raw message