apr_queue_pop/push (Was: Re: Performance fix in event mpm)

[Jim Jagielski <ji...@jaguNET.com>]

Looping in APR as well...

On Jan 27, 2011, at 1:43 PM, Jim Jagielski wrote:

> 
> On Jan 27, 2011, at 1:31 PM, Jim Jagielski wrote:
> 
>> 
>> On Jan 27, 2011, at 12:21 PM, Jim Van Fleet wrote:
>> 
>>> I noticed that ap_queue_pop removes elements from the queue LIFO rather than FIFO.  Also noticed that apr_queue_pop uses a different technique which is not too expensive and is fifo, so I changed ap_queue/pop/push to use that technique and the receive problems went away.
>> Hmmm.... Not sure why the fdqueue would be LIFO. But certainly
>> the above ain't right for pop! :)
> 
> OK, looking over the history, it looks like the Q was changed from
> FIFO to LIFO ~10years ago (worker)... The reasoning:
> 
>  This is a rather simple patch that may improve cache-hit performance
>  under some conditions by changing the queue of available worker threads
>  from FIFO to LIFO. It also adds a tiny reduction in the arithmetic that
>  happens in the critical section, which will definately help if you have
>  a lame compiler.
> 
> Seems to me that changing back to FIFO would make sense, esp
> with trunk. We can profile the expense of the '% queue->bounds'
> but it seems to me that if it was really bad, we'd have seen it
> in apr and changed it there... after all, all we're doing
> with that is keeping it in bounds and a comparison and subtraction
> would do that just as well...

Doing some profiling, we can improve things more in apr_queue_pop/push...

    a++;
    if (a>=bounds)
      a -= bounds;

is about 2-4 times as fast as:

    a = (a+1)%bounds;

Seems like an EZ and obvious optimization to me ;)