I'm not really sure what this big debate about. I'm sure that everyone agrees (not least of all me!) that the GC patch should be thoroughly tested for performance and stability before being released to the public. I mean, something that affects the life-cycle of every zval definitely has to be.
However, many people are hypothesizing that GC might be slow, as much as 10% even. I know this is just being used as an argument for more testing (which I totally agree with) but I feel like it's been discussed so much that I need to step up and defend my baby. ;) About 25% of my time was spent actually getting the GC to work right. 75% of it was trying to make it work fast. I'm definitely not naive about PHP's use in enterprise applications where a few % really does matter and I've been on the list long enough to know that a lot of people here care about those few % as well. :) My basic principle was that "People who don't need or don't want GC should not see any performance impact," and I believe I have achieved that. (There was also an addedum "if necessary, at the expense of people who do need or want GC" but shhh ;)) There are various housekeeping tasks that must be written into the engine that can't really be configured out after compile. I tried to keep the impact of those as low as possible. I went as far as using callgrind to make sure L1 cache misses were kept low. As it stands right now, I don't see any significant performance impact on bench.php (which I think would be a good test of those changes), not even 0.1%. Then there are greater pieces of maintenance that must be performed to keep track of possible gc targets. Those can be configured out using php.ini or even user level functions. Users can safely control at the script level whether they want GC or not. However, those aren't even very costly since they also don't make a (measurable on my setup) difference on performance but the impact of these functions are more script dependent and will require more testing. However, in most cases, you should be able to leave GC enabled and not see any performance impact because the part the impacts performance significantly: the collection, only happens when the number of collectable cycles you have is above a (very large) threshold. That's not going to happen during most scripts (where memory consumption is low and run time is short). GC is not fully ready yet. It really MUST be tested on a wider scale, and on more real-world applications, and I think everyone agrees. Without testing, It's even too early to tell how much more work it needs yet. I spent an enormous amount of time and effort trying to make GC as fast and painless as possible and I'm extremely eager for others to begin testing it to see if the time I invested has paid off. David On 9/9/07, shire <[EMAIL PROTECTED]> wrote: > > On Sep 8, 2007, at 9:31 AM, Antony Dovgal wrote: > > > > > If these companies really do worry about this %, why don't they > > participate in development and/or testing? > > I don't recall seeing any contributions or even feedback from > > Facebook or alike, do you? > > > > If they wait for a release to test and complain, then I couldn't > > care less - it's just a common > > development process, bugs come and bugs go, I see no reasons why we > > should make an exception for > > a company that doesn't give a damn about us. > > I realize that this conversation isn't really about Facebook, but > while it's been brought up I'd like to step in and say that Facebook > is *very* interested in helping with PHP development and other open > source projects. We are always trying to run the latest CVS or RC > versions to make sure we don't find any problems or performance > losses (although we do occasionally fall behind which is unfortunate > for us). If there are any new patches that the developers think we > could help test out for performance and stability I'm very happy to > do so. > > There have been a handful small contributions to APC, PHP, and > others, and I'm excited that we get to work on these projects and I > hope myself and others at Facebook will be able to continue to make > useful contributions. I'm also grateful for the contributions others > have made here, and I hope Facebook and myself can establish itself > as an entity dedicated to giving back as well. If you have other > questions or suggestions please feel free to email me, I know I've > limited my posts here so as not to add anything unnecessary but we > are here and ready to help. > > Thanks, > > -shire > Facebook Inc. > [EMAIL PROTECTED] > > -- > 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
