FW: Patch for macros for tracking refcount and is_ref View as Markdown

Facebook is quite active in APC development.

I'm glad for APC, but this is a separate project (or a sub-project, whatever).

And yes, if it turns out to be 10% slower, a lot of sites are going to want to run without it.

Right, but saying that we should be especially careful because this patch may affect company XXX makes no sense to me.
Either this company is interested in this patch and helps us to make it better, or we follow the usual development process
(i.e. try to make it as better as we can and release when it's ready, but we don't test it for years to stabilize it).

For scripts that aren't very complex and don't run for a long time, GC
simply isn't a very interesting feature.

Well, for not very complex scripts most of the engine improvements are not very interesting.

--
Wbr,
Antony Dovgal

And yes, if it turns out

to be 10% slower, a lot of sites are going to want to run without it.

Sad, I see you have lost the notion about who are the vast mayority of
your users.

Facebook or any top site that requires extreme performance represents
a very small (less than 10%) of your real users.

Instead of discussing about speed, I think we should talk about proper
behaviuor first, premature optimization is an horrible bad thing.

--
http://www.kissofjudas.net/

Uhm I didn't mean to make this about one company or another (it was just an example,
and btw, I think they've contributed to APC :) and this discussion is going very much
of track. I guess you either didn't understand what I was saying or don't realize
that this is not necessarily going to be applicable to everyone (although it may
depending on how it performs; and I hope it is applicable to everyone).

Well, it was difficult to understand it wrong: you said that it's a major change and
it should be tested well (I completely agree with that).

But I don't see why we should especially care of a particular company which MIGHT be affected by this patch.
Either they care about it and help us with to make it better, or we do & test it as good as we can.

I'm also just
saying that it may need some time to mature like many patches which are so deep.

Sure, that's obvious.

--
Wbr,
Antony Dovgal

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

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.
shire@facebook.com