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 [EMAIL PROTECTED] -----Original Message----- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] 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
