apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: Pools rewrite [3]
Date Thu, 06 Dec 2001 19:56:38 GMT
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



Mime
View raw message