Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33629
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain Opus1.COM designates 192.245.12.9 as permitted sender)
Date: Mon, 03 Dec 2007 23:46:13 -0800
In-reply-to: <698DE66518E7CA45812BD18E807866CEF890C7@us-ex1.zend.net>
To: Andi Gutmans <andi@zend.com>
Cc: internals@lists.php.net
Message-ID: <FC0AB1F9-D444-4FFC-B837-1C6A74015874@Opus1.COM>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7bit
References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net>
 <B2740BB0-5215-4018-BEFA-41FC123C81C5@opus1.com>
 <698DE66518E7CA45812BD18E807866CEF890C7@us-ex1.zend.net>
Subject: Re: [PHP-DEV] Garbage collector patch
From: ron@Opus1.COM (Ronald Chmara)

On Dec 3, 2007, at 10:30 PM, Andi Gutmans wrote:
>> -----Original Message-----
>> From: Ronald Chmara [mailto:ron@Opus1.COM]
>> What is the *actual cost and complexity* involved in implementing
>> (possibly many) different user-selectable memory management systems,
>> and what other future benefits/drawbacks might we see by doing such a
>> thing? (GC is big now, but what about memory pools per mod_auth user,
>> or SHM/SEM pools, or tuning amounts of memory per function, etc...)
>>
>> I will now apologize to everybody who I just made cry, scream, or
>> damage their furniture, as I didn't mean to hurt you, just trying to
>> stimulate ideas.
>
> Hi Ronald,
>
> PHP 5.2.x already supports the ability to hook in different "page"
> managers. In PHP 5.3 you can also override the memory allocation
> functions. However, this would not include garbage collection like
> algorithms which actually require changes in the core PHP data type  
> such
> as zvals. In fact the garbage collection adds memory to the basic
> datatypes which is why I suggested to either always make these  
> changes,
> or don't make them so that we retain binary compatibility across all
> builds of PHP.
> So overriding basic memory allocation functions, yes, ability to  
> provide
> various GC implementations, no.

Okay, so, without this patch, I can allocate mem, and destroy it, on  
a per page level, but not on a zval level, and the choice is:
a) zval (etc.) destruction with this patch, which has a 5% speed hit  
at times (varies per test)
b) no patch, no change
c) something which hasn't been thought of yet?

I'd have to (sadly) ask that anything that slows down PHP by 5%, to  
improve performance for programmers that, uhm, "leak" or otherwise  
gobble RAM, that they, uhm, refactor their code as professional  
programmers.

Thanks for clearing it up for me, Andi.

-Bop