Good idea, but it allows only memory_get_usage() and not memory_get_peek_usage() :(
Dmitry. > -----Original Message----- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
