> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>
> "Ryan Bloom" <[EMAIL PROTECTED]> writes:
>
> > > I suspect that rebuilding the native pollset (e.g., struct pollfd
> > > array) every time apr_poll() is called is harmful to Apache.
> >
> > It should actually perform better than the previous version of the
code,
> > for small pollsets, which is what most people use with Apache.
>
> I started off agreeing that the new implementation is faster for small
> pollsets, but I'm not sure that is the case when you consider
> steady-state operations. We save the overhead of the function call to
> look up the returned events after the poll call but we pick up the
> overhead of the internal call to get_event() just before poll() is
> called.*
That get_event() call can easily be removed in 99% of the cases (see
below).
> If APR had a small-pollset API and a big-pollset API, I suspect we'd
> be better off in Apache just using the big-pollset API rather than
> deciding at run-time which API to pick since implementing a choice
> would likely introduce an extra function call which would erase any
> small benefit of being able to use the small-pollset API.
In how many situations would we actually need to use the big-pollset
API? I would much rather just write the code to use the small-pollset
API, and possible #ifdef the big-pollset API. It would be faster to use
the small-pollset API, and if you _must_ have the large-pollset, then
you configure for it.
> > > I suspect that rebuilding the abstract pollset (apr_pollfd_t
array) in
> > > its entirety after calling poll() is harmful to Apache, which is
only
> > > going to process the first match.
> >
> > I am unable to parse this at all. If you are talking about the
current
> > implementation, then one of the advantages is that you don't need to
do
> > that anymore.
>
> Here is the code I referred to as "rebuilding the abstract pollset
> (apr_pollfd_t array):"
>
> for (i = 0; i < num; i++) {
> aprset[i].rtnevents = get_revent(pollset[i].revents);
> }
>
> *yeah, calling from Apache to APR is more expensive than an internal
> APR call, but are we digging that deep to find the benefit?
This is a straight bit-mask check, and in most cases, can be optimized
out to a no-op. We have to write the optimization, but 99% of the time,
the function call can be removed. As for the first/all rtnevents
decision, Apache should be using all of the results. We don't
currently, but we could and should.
