Re: Garbage collector patch

Sorry to intrude on this one! It seems that some real hard work has gone into this, and a big thanks from the community for all your hard work. Can the gc patch feasibly be improved any more? If so surely the time scales involved with improving further would mean it'd miss the boat for a 5.3.x release..? Real-life use of PHP has to be the foremost concideration; in the production environment, especially on server farms and shared hosts, how many of them are going to be upgraded to 5.3 anyways, and when so, not for a long time (sadly)! 4 bytes vs the earlier 12 bytes is a significant improvement, and much as this may seem a terrible thing to say.. Roll it out in 5.3, turned on by default (with option to disable at compile time) - that's your test right there, if there are problems then have it disabled by default in the subsequent minor release. My only (and major) concern as an end developer is the 5% slowdown and 3% memory overhead, exactly what benefit am I as an end developer going recieve for this? Andi started this series with : "On one hand I think now the effort has been made it's a good thing to offer it as part of PHP"; and I for one agree, with the emphasis on *offer*. Many Regards & Apologies for the intrusion. Nathan Andi Gutmans wrote:

Hi Ilia, I suggest more people test the performance difference because as you can see for us it was negligible. From my experience you see bigger deviations just by moving kernels, compilers, and even small patches which affect where in memory the code segments sit, etc... Maybe some people here who have performance harnesses (I'm sure Yahoo! has one) could test it too. Andi

-----Original Message----- From: Ilia Alshanetsky [mailto:ilia@prohost.org] Sent: Saturday, December 08, 2007 9:35 AM To: ceo@l-i-e.com Cc: Rasmus Lerdorf; Stas Malyshev; scott.mcnaught@synergy8.com;

'Antony

Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Richard, zval is such a common PHP structure that in a scope of a single script (even a trivial one) you'd have thousands of them. Therefor even an extra 4 bytes matter, and for people with large application it would matter even more. I wish the patch was such that it had no impact on the people who don't need it, but the reality is that for anyone who does not need gc cycles, it'll be a performance (speed & memory) penalty. This is why I had intimately suggested making it a compile time, configuration option. On 7-Dec-07, at 9:25 PM, Richard Lynch wrote:

On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote:

Stanislav Malyshev wrote:

1. Always compile it in but leave undocumented #ifdefs in place

for

performance freaks. Those same performance freaks aren't going

to

care about the binary compatibility issue since they are the same

people

who build all their own stuff.

Note that breaking BC is not only about performance - one your

build

is not the same as mainstream PHP, you can't use any binary extension which would do anything non-performance-related - like interfacing some external system/library, debugging, profiling, testing, security

and

so on. Any commercial module won't be available for the user of this switch, and all open-source modules one'd have to build by oneself, which may be serious maintenance issue. I know there are a bunch of companies that compile PHP with their own options but still use commercial

modules,

including both performance and non-performance ones. They couldn't use this compile switch.

Yes, I know what binary compatibility means.

Call me crazy, but... Would it be possible to hard-code the bit that adds the 4 bytes to

the

zval, but make the execution bit a flag so that binary compatibility is always there, but the executable code that does the GC can come

or

go as needed?... Or am I just talking nonsense due to ignorance? -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Ilia Alshanetsky