Hi Dmitry, Ilia, et al., Ilia, the Memory Manager is checking the *real* size against memory_limit, so it's still "more accurate" even after the functions were changed to report more like the old way. I still wonder how much difference there may be between size and real_size as it gets close to the limit...
After the changes, I see the usage difference after adding a variable, for example, is slightly different than before, but I understand that's because of counting overhead now or such. The old one just rounded the amount up to a multiple of 8, I think... Something else I'd like to see changed... Does anyone think memory_get_[peak_]usage() should *always* be available, regardless of whether memory_limit is actually enabled? Using the Windows binaries at least, I was devastated :-D that they were unavailable for experimenting, etc. I don't see why not -- the function names IMO don't really suggest that they're tied to memory_limit and all that's being saved by not having them is a little overhead of updating the size/peak variables, right? Thanks, Matt ----- Original Message ----- From: "Ilia Alshanetsky" Sent: Tuesday, July 25, 2006 > The idea of a memory limit is to as accurately as possible account > for the memory utilized by PHP. If our current calculation is more > accurate since it accounts for malloc overhead, great, it gives more > fine grained control to hosters utilizing this option. > > > On 25-Jul-06, at 9:45 AM, Lukas Smith wrote: > > > Dmitry Stogov wrote: > >> Right now memory_get[peak_]usage() show the amount of REAL memory > >> that PHP > >> (Zend Memory Manager) takes from system. > >> Previous memory manager showed size of emalloc()-ed memory without > >> malloc() > >> overhead. > >> Also it didn't consider internal caches. > > > > Shouldn't we make the old behavior the default here? > > > > regards, > > Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
