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