Unfortunately it also takes more memory in the common case (at least the apps that we tested). It's not a significant amount more but it's a tiny bit more. I'd say negligible. Btw, I think I miswrote in my email. When you look at the benchmark results on the new patch it's actually 1-2% slower and 0-3% more memory. I think even on a heavy duty server that is likely not to have much impact. I'm sure just the fluctuations between hardware architectures and compilers will often create bigger differences.
To clarify I meant there's a tri-state (not compiled in, compiled in but collection turned off, compiled in but collection turned on). My recommendation was to always compile it in but to keep collection turned off by default. I am also OK with trying to keep collection turned on as long as we have an INI parameter to turn it off when things go wrong (it can be hidden, i.e. doesn't show up in phpinfo() nor php.ini). Unfortunately there are certain areas of PHP which took more than a few months to stabilize. Not sure this would be the case here but better safe than sorry and have way to turn it off. You can never know what weird memory patterns in extensions and SAPI modules will lead to crashes. Andi > -----Original Message----- > From: Guilherme Blanco [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 04, 2007 11:59 AM > To: [EMAIL PROTECTED] > Cc: Rasmus Lerdorf; Antony Dovgal; Andi Gutmans; Cristian Rodriguez; > internals@lists.php.net > Subject: Re: [PHP-DEV] Garbage collector patch > > 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
