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

From: Date: Sun, 09 Jun 2002 04:11:41 +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-85056@lists.php.net to get a copy of this message
At 04:57 PM 6/8/2002 -0700, Brian Pane wrote:
Zeev Suraski wrote:
At 12:55 AM 6/9/2002, Brian Pane wrote:
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).
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:
     - 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.
It sounds to me as if we're going to have to write a new allocator with the same semantics as the Win32 API one. I don't think any of these two allocators would suit us very well. Andi

« previous php.dev (#85056) next »