Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25381
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <009101c6c13d$7c5440a0$0201a8c0@pc1>
To: <internals@lists.php.net>, "Stefan Esser" <sesser@php.net>
References: <20060816123006.4028b334@pierre-u64> <44E3121B.7070904@php.net>
Date: Wed, 16 Aug 2006 09:08:44 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] increase the default memory limit in 5.2.0+
From: php_lists@realplain.com ("Matt W")

----- Original Message -----
From: "Stefan Esser"
Sent: Wednesday, August 16, 2006


> Hello,
> > After having tested 5.2 and the new memory manager for a couple of
> > weeks, I notice a significant increase of the reported memory usage. As
> > a side effect, many applications reach the 8M memory limit. It can be
> > a problem.
> >
> > A good example is to compare the usage of a pear/pecl command between
> > 5.1 and 5.2.
> >
> The question is why do we want a new memory manager that seems to
> allocate 1.5 times more memory than the old one.
> I haven't looked into it yet, but for me this looks like a waste of
> ressources. What are the advantages of it. I really doubt,
> that a significant speed increase can be measured, and I wonder if it
> worth the waste of memory.

I found there was about a 10% difference overall (Windows) before/after when
running the Zend/bench.php script -- some parts are ever-so-slightly slower,
but things like string concatenation (erealloc()...) are massively faster.
And I know Andi has said it's supposed to perform better under load and over
time.

About the memory usage amount, I had mentioned the following in a previous
discussion, but I guess I'm wrong, so I don't want to be annoying. :-)  I
found that emalloc()'ing big chunks anyway (many MB+) on Windows (assume
others are the same), *doesn't actually* take "real" memory from the system
(only VM) unless or until it's actually filled with something ("used"),
which makes sense.  So I was wondering why the overhead (where the "higher"
usage comes from) even needed to be counted with the new manager...?  But,
maybe that's only with larger chunks that it's not "really" taken, or it
changes over time with fragmentation or something...

Actually, after typing that, it probably is wrong for the way I think the
Memory Manager handles its small blocks!  (efree()'d space isn't returned?
But dunno when/if the blocks are truely free()'d.)

> Yours,
> Stefan Esser

Matt