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, <[EMAIL PROTECTED]> 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 > [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 > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com São Carlos - SP/Brazil
