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,
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
