Sander Striker wrote:
...

*) The performance gain is in not having to walk the list of nodes in
apr_pool_clear as mentioned above. Maybe this is not really a performance
win, but more of a better devision of processing time. apr_pool_clear
and apr_pool_destroy have less work to do, this could be why TStd is down(?).



Optimizing away the walk of the node list in apr_pool_clear isn't a big win. The node list is usually just one or two nodes. And if it's ever considerably longer than that, it's because we've done either a lot of allocs from the pool or a few allocs of big structures-- and in both of those cases, the cost of the pool cleanup is usually going to be trivial compared to the cost of the code that's using the pool.

The main reasons for the reduction in usr CPU utilization with your
new code seem to be:
 1. The elimination of a lot of mutex lock/unlock calls, and
 2. The use of the new lock API, which doesn't spend lots of time
    looking up the current thread ID the way the old one does.

However, if you decide to keep the current code arrangement (with the
reset of the first_avail pointer in apr_palloc), I won't object.

--Brian




Reply via email to