> From: Brian Pane [mailto:[EMAIL PROTECTED] > > 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] > > > >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
