Ancak çoğu durumda bu performans vs kolaylaştırmak için aşağı gelir, yine bu konu hakkında karışıklık var gibi görünüyor.

Okumak için iyi bir posta listesi konu Zend Altyapıları posta listesinde bu bir olurdu:

http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html

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.

source: http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html#a640092