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, <[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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
