Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter

Andi Gutmans wrote:

I just checked and it seems like Apache APR memory pools use mutex locking. It'd be better to use functions like the Win32 ones which don't use mutex locking (as we made sure that only one thread allocates from its pool). This could be achieved by compiling apr_pools.c without APR_HAS_THREADS but I bet the default Apache 2 build has this enabled. Any ideas? Andi

It's not as bad as it looks. :-) The APR pools do locking only in a few situations: * Creating a new pool * Creating a subpool of a pool * Destroying a pool * Adding space to an existing pool, if it's used up its initial 8KB allocation So the simplest case, the lifetime of a pool looks like: - create the pool, requiring a lock/unlock - do hundreds of allocations from the pool, none of which require locking - destroy the pool at the end of the request, requiring one lock/unlock for the entire thing In general, that model works well: over the lifetime of a pool that handles O(n) allocation operations, we only have to do O(1) lock/unlock operations. But there's an additional optimization that's possible: Sander Striker added support for thread-specific allocators a while back. The per-request pools in most of the Apache 2.0 MPMs take advantage of this. Each pool has an "apr_allocator" object that supplies it with raw memory blocks. These allocators can be designated as either thread-private or shared across threads. And a thread-private allocator gets to skip the mutex operations. If you want to try the APR pools, the easiest approach might be to either use the request_rec->pool directly or create a sub-pool from it. --Brian