Re: Garbage collector patch

In general this patch will use more memory. (4 bytes more for each heap allocated zval). The only advantage is automatic cycle collection, but most web applications doesn't make cycles. Dmitry. Guilherme Blanco wrote:

I want to put my 2 cents, but before make any comment, I'm interested to know if it's only a performance impact. Talking about performance is ok and I agree that any penalty should be taken into account, but if the patch uses less memory resources, I think that shared hostings will care about it. I remember when you released PHP 5_2, that was around 12% slower than any version of PHP 4. None care about it, and only in PHP 5_2 you took into account and optimized it a lot. As long as it uses less memory, it should be added into 5_3. Wang spent a lot of efforts to create the patch, Dmitry too. Also, I think you should take care of 5% of performance penalty is not huge if you consider that now you have a nice implementation of what was not working correctly (referring to circular references). But... if it uses more memory... I stay in the middle of the sides. Too much more? This is a factor. Besides all of this argumentation of performance... I'd go with Andi's first suggestion. No config for it... in or out. Make it configurable may generate some BC incompatibilities. Regards, On Dec 4, 2007 5:45 PM, <scott.mcnaught@synergy8.com> wrote:

I think having it configurable is a must. Turning it on / off via a compile flag will not suit everyone. Eg - I have a situation where I would not want to run garbage collection for web pages served off my server due to the performance hit, however I also have a CLI script which I run to do complex, but repetitive tasks for ~half an hour. Now this is not really a big deal to me as I managed to rid most of the leaks by nulling out cyclic references, however that took a lot of work which could have been avoided by this. Could I suggest also enabling it by default for CLI? SCOTT MCNAUGHT Software Developer Synergy 8 / +617 3397 5212 scott.mcnaught@synergy8.com -----Original Message----- From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com] Sent: Wednesday, 5 December 2007 5:17 AM To: Antony Dovgal Cc: Andi Gutmans; Cristian Rodriguez; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Antony Dovgal wrote:

On 04.12.2007 18:31, Andi Gutmans wrote:

You may be right longer term but shorter term I still believe there may be stability issues with this patch some of which we haven't figured out. Although we did testing and found crash bugs I wouldn't trust our level of testing to deem it stable. If we go down the route of always on we could have a hidden ini file (not listed in php.ini-dist and phpinfo()) which we can advise to turn off if something goes wrong and once we can enough confidence that there aren't any lurking bugs we could remove it.

You mean provide an ini setting to be able to turn it Off? But why do you call it "always On" then? And what's the difference comparing to what you've proposed earlier? Concerning the stability issues, I'd say we have quite good chance to make it stable enough, as (I hope) 5.3.0 is not going to be released for at least several months more. Companies that are especially concerned of performance/stability are encouraged to step forward and give us a hand.

Companies concerned about performance aren't going to use it at all. A 5% hit is significant given that it doesn't fix anything that a company already concerned about performance/stability cares about. Super leaky or recursively allocating scripts have long since been weeded out of those code bases, so it is a 5% performance hit with no gain. I am not arguing that it isn't useful in the general case. It will make PHP more robust on loosely controlled servers for what amounts to only a small penalty, but at the same time it is an easy 5% win for people with dedicated servers running well-written code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php