Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24995
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <00ed01c6b163$c3d40ad0$0201a8c0@pc1>
To: <internals@lists.php.net>
Cc: "Dmitry Stogov" <dmitry@zend.com>, "Ilia Alshanetsky" <ilia@prohost.org>
References: <00d601c6af9d$c18f2d30$0201a8c0@pc1> <003701c6afb1$81b87720$6e02a8c0@thinkpad> <44C6205F.4090808@php.net> <BD9A2C99-06B8-4C23-A0B7-B5150BDB890B@prohost.org>
Date: Thu, 27 Jul 2006 05:02:26 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager
From: php_lists@realplain.com ("Matt W")

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