Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (athena.apache.org: 76.96.30.48 is neither permitted nor
 denied by domain of jim@jagunet.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: apr_queue_pop/push (Was: Re: Performance fix in event mpm)
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <5BC93482-6F60-425A-B3D5-2872A9AB1FDF@jaguNET.com>
Date: Thu, 27 Jan 2011 14:05:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F98D193-04AD-420B-A699-849BFFEC8DC9@jaguNET.com>
References: <106824.42931.qm@web120611.mail.ne1.yahoo.com>
 <64BCE379-9236-4C9B-B407-4B046CE7922F@jaguNET.com>
 <5BC93482-6F60-425A-B3D5-2872A9AB1FDF@jaguNET.com>
To: dev@httpd.apache.org,
 APR Developer List <dev@apr.apache.org>

Looping in APR as well...

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

>=20
> On Jan 27, 2011, at 1:31 PM, Jim Jagielski wrote:
>=20
>>=20
>> On Jan 27, 2011, at 12:21 PM, Jim Van Fleet wrote:
>>=20
>>> 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! :)
>=20
> OK, looking over the history, it looks like the Q was changed from
> FIFO to LIFO ~10years ago (worker)... The reasoning:
>=20
>  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.
>=20
> 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>=3Dbounds)
      a -=3D bounds;

is about 2-4 times as fast as:

    a =3D (a+1)%bounds;

Seems like an EZ and obvious optimization to me ;)=