RE: [PHP-DEV] memory_get_usage with new Memory Manager
| From: | Dmitry Stogov | Date: | Fri, 28 Jul 2006 06:56:12 +0000 |
| Subject: | RE: [PHP-DEV] memory_get_usage with new Memory Manager | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-25028@lists.php.net to get a copy of this message | ||
Good idea, but it allows only memory_get_usage() and not
memory_get_peek_usage() :(
Dmitry.
> -----Original Message-----
> From: Andi Gutmans [mailto:andi@zend.com]
> Sent: Friday, July 28, 2006 5:43 AM
> To: 'Ilia Alshanetsky'; 'Ron Korving'
> Cc: internals@lists.php.net
> Subject: RE: [PHP-DEV] memory_get_usage with new Memory Manager
>
>
> I personally think that we should keep the more accurate
> behavior both because it's the most accurate and what most
> people would expect when setting memory limits, and because
> it does allow us to always enable memory-limit code due to
> the significantly smaller overhead of keeping count. If some
> people really feel it's important for debugging purposes to
> be able to tell how much memory has been emalloced() (i.e.
> how much size PHP has requested as opposed to how much memory
> is being managed), then we could add some slow functions that
> traverse the memory manager and provide that information. For
> debugging purposes that would be sufficient but will not
> clash with us fixing the memory limit to start working much
> better and more efficiently.
>
> Thoughts?
> Andi
>
> > -----Original Message-----
> > From: Ilia Alshanetsky [mailto:iliaal@gmail.com] On Behalf Of
> > Ilia Alshanetsky
> > Sent: Thursday, July 27, 2006 10:33 AM
> > To: Ron Korving
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
> >
> >
> > On 27-Jul-06, at 1:17 PM, Ron Korving wrote:
> >
> > > Yes, hosting providers would enable the memory limit. But
> > who wants to
> > > use memory_get_[peak_]usage()? Not the hosting provider, but the
> > > application developer.
> > >
> >
> > The peak usage function was added with profiling in mind and
> > keeping track of scripts that spike memory, when I added it
> > the intent was it would help with profiling and debugging.
> > Not something used everyday in production environment. In dev
> > environment speed is not an issue, so you can enable memory
> > limit and raise the limit to some very high value such as 1Gb
> > so it does not get in the way.
> >
> >
> > Ilia Alshanetsky
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List To
> > unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>