Re: Garbage collector patch
| From: | Rasmus Lerdorf | Date: | Tue, 04 Dec 2007 19:16:39 +0000 |
| Subject: | Re: Garbage collector patch | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-33681@lists.php.net to get a copy of this message | ||
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