Re: memory_get_usage with new Memory Manager
| From: | Matt W | Date: | Tue, 25 Jul 2006 11:32:37 +0000 |
| Subject: | Re: memory_get_usage with new Memory Manager | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-24964@lists.php.net to get a copy of this message | ||
Hi,
That's what I was thinking too, Ron. Internally, the functions
zend_memory_[peak_]usage() would also get a flag parameter, or separate
functions...
There's also the small issue of which size to set Apache's mod_php_mem_usage
to.
Dmitry, et al., I don't know the details of how the Memory Manager works,
but I assume multiple memory blocks can have free space (if something didn't
fit, and now block(s) were allocated). So if memory_get_usage() operates
like before (reflecting small changes) and it's being used to make sure to
stay under memory_limit, for example, memory_limit could be exhasted sooner
than expected since the REAL allocated size is compared with heap->limit.
Could/should the limit be compared to size that's measured the old way, or
might that allow too much to "escape?"
Hope you don't mind my random thoughts. :-)
Matt
----- Original Message -----
From: "Ron Korving"
Sent: Tuesday, July 25, 2006
> Perhaps it'd be a nice alternative to have an optional parameter? Having 4
> functions for checking memory usage is quite a lot, isn't it?
>
> I would humbly prefer seeing:
>
> int memory_get_usage([bool realusage])
> int memory_get_peak_usage([bool realusage])
>
> - Ron
>
>
> "Derick Rethans" <derick@php.net> schreef in bericht
> news:Pine.LNX.4.62.0607251122250.5096@localhost...
> > On Tue, 25 Jul 2006, 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.
> >> > >
> >> > > We need decide which behavior to use before 5.2.0 release.
> >> >
> >> > I would definitely want a more precise memory usage.
> >>
> >> We can revert "allocated_memory" semantic.
> >> This is not a problem.
> >>
> >> > However, we can add the new one as a different function (or atleast
> >> > some internal value in AG).
> >> >
> >> > For now, this change breaks some BC with extensions (like Xdebug)
> >> > that use AG(allocated_memory).
> >>
> >> Please use new API functions to access them.
> >
> > What are the new functions?
> >
> > Derick