Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter
| From: | Aaron Bannert | Date: | Sun, 09 Jun 2002 19:53:55 +0000 |
| Subject: | Re: Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter | ||
| References: | 1 2 3 4 5 6 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-85069@lists.php.net to get a copy of this message | ||
On Sun, Jun 09, 2002 at 03:09:24AM +0300, Zeev Suraski wrote:
> Hmm, but doesn't that mean that the largest contiguous block this heap will
> be able to provide is 8KB, then?
8K is just the minimum chunk size, there is no absolute maximum.
> > * 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.
>
> This is probably not very suitable for PHP. We allocate and free *a lot*,
> not being able to free is going to increase memory consumption
> significantly. If we use APR heaps, are we bound by this behavior?
The expectation is that pools are cleared at normal intervals, so
that eventually the memory allocation for an application reaches a
"steady state". In PHP this could be accomplished by simply using
the per-request pool that is already available when the internal PHP
functions are called from httpd. At the end of a request this pool is
"cleared", and then able to be reused on subsequent requests.
-aaron