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
