Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter
| From: | Brian Pane | Date: | Sat, 08 Jun 2002 23:57:46 +0000 |
| Subject: | Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter | ||
| References: | 1 2 3 4 5 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-85054@lists.php.net to get a copy of this message | ||
Zeev Suraski wrote:
At 12:55 AM 6/9/2002, Brian Pane wrote:In the httpd, we've done two things to minimize the fragmentation: * Memory for these heaps is almost always allocated in chunks of a fixed size, 8KB. * There's a two-layer structure to the heaps:I just looked through zend_alloc.c. It looks like the HeapCreate only happens once, at startup--did I get that right?It's called on the per-thread startup (start_memory_manager(), which is called from alloc_globals_ctor(), which is the per-thread allocation 'constructor').For PHP processing, do you need a memory heap that is created at startup and used by all requests, or is it sufficient to create and destroy a private heap for each request?We can go either way, but won't allocating and freeing these heaps increase fragmentation? Remember that PHP functions will also allocate memory outside these heaps (in 3rd party libraries).
- apr_pool objects are what the application uses. Each pool
provides a fast alloc interface, no free function, and a
"destructor" that returns all the allocated space when the
pool is destroyed.
- apr_allocator objects provide blocks of memory for the
apr_pools to use. Each apr_allocator maintains a free
list of blocks. When a pool is destroyed, its space is
returned to the apr_allocator from which it was created.
The next time we create a pool from that apr_allocator,
we can take an 8KB block from that allocator's free list
rather than interacting with the system heap.
--Brian