Hi,
I think that I speak for everybody when I thank you for this clear
explanation. I've got a small question still. (I hope it is the last)
Is compile-time binding for class B done in script:
require('a.php'); // defines class A
class B extends A { /*code*/ }
And in:
require_once('a.php'); // defines class A
class B extends A { /*code*/ }
Or only in:
class A { /*code*/ }
class B extends A { /*code*/ }
Thanks a lot for clearing up this final point,
Arnold
Stanislav Malyshev schreef:
In "Paddy speek", I was referring to this blog entry which more or
less suggests (sort of conclusively unless its yet more FUD, dumped
on previous FUD, amounting to a big fat FUD in which case I give up ;))
http://pooteeweet.org/blog/538
Maybe someone enlightened can point out what's wrong with that entry? It
Well, where do I start? :) It is not 100% clear what Rasmus was
meaning there (I guess it might be because he talked to somebody
sharing some conversation context that we do not have) but from the
following conversations it seems that the idea was that autoload
supposedly defies compile-time binding. This is not exactly what is
happening - here we have the fallacy of correlation instead of
causation. Using autoload by itself does not cause the problem. What
causes the problem (one instance of the problem, most frequent one) is
inheriting class from other class, which is not known to the engine at
the time of compiling the child class, or defining class in
conditional context (i.e. inside if() or function).
Now, the correlation is here because if you inherit from
not-yet-defined class, you might rely on autoload to define it (though
you might also rely on include), and actually the presence of the
autoload facility may encourage you to use such inheritance. But this
is not the autoload which brings trouble (see after Ramus' "it's not
just autoload" in the blog for some examples of troublesome things).
So the right phrase would be "people which tend to rely on autoload
tend also to use code which defies compile-time binding". Which can't
be seen as autoload fault, of course, and just avoiding autoload won't
help a bit with that - you would also have to rewrite your code so
that compile-time binding could happen. And it has nothing to do with
uses of autoload with "new", for example.
As for the slowdown from the effects described above - i.e., absence
of the compile-time binding - the code indeed becomes a bit slower and
such code can lead in some obscure cases to some trouble to opcode
caches (not in the autoload cases - but in cases where classes are
defined inside conditions, or, God forbid, different definition is
created depending on condition) - but it has next to nothing to do
with using autoload by itself.
The amount of slowdown, however, seem to be greatly exagerrated by
people - it is nothing (and I repeat to be clear - *NOTHING*) compared
to the performance benefit given by the opcode cache due to the
absence of the disk operations and compilation stage. You could
probably compose an artificial benchmark that would show some
significant slowdown, but I do not believe any real application would
even notice.
So we should set the priorities straight - if you talk about sites
like Yahoo! where saving one function call per request may mean ten
less servers in the farm, it may make sense to take into account all
the obscure stuff and try to squeeze out every last bit - including
never relying on autoloading but instead always keeping the context in
mind and using carefully crafted include statements to load all
classes at the top of the application. However, let's not overestimate
the gain there - it's quite small. And doing it right in the framework
context is quite hard (if you wonder, just replacing autoloads with
requires at the top of the file probably is not going to do a thing,
you have to change the whole include structure to do the compile-time
binding right). SO I don't think it's worth the trouble.
P.S. Disclaimer: since I am not Rasmus and I can not read his mind, I
can not be sure what I understood is exactly what he meant, and I very
much welcome everybody who thinks I'm wrong to prove so. I also do not
know internals of the APC, so it might be that APC has some quirks
that I miss. On the other hand, I know very well the internals of the
other opcode cache - namely Zend Platform - being one of its authors.
I believe APC is built on the same principles, though.
HTH,
