I see at least one benefit to using autoload - load classes only as-needed. Changes to code/framework frequently need a re-visit to the require*() calls to see if any classes are loaded superfluously. Some classes loaded superfluously could load additional classes that may also be superfluous in a dynamic situation. But I'm still not clear with op-code caches as some say they had issues while others say they had no problems using them with autoload. Maybe, these got resolved with the later versions of PHP/op-code caches?
Regards, On 1/2/07, Bill Karwin <[EMAIL PROTECTED]> wrote:
Lee Saferite wrote: > Anyway, could someone smarter than me give an intelligent reason we do > not use this function? Tony Hoare is a very smart man, and he said: "Premature optimization is the root of all evil." This is known as Hoare's Dictum. See http://en.wikiquote.org/wiki/Tony_Hoare Donald Knuth is also very smart, and he has quoted the above principle frequently. If a given optimization only improves performance in a fraction of cases, and it introduces potential complexity or breaks in certain environments, is it worth pursuing the optimization? It may become apparent that a different optimization is much simpler, gives more benefit, and works in more environments. But we won't know which are the best improvements until the code is more functionally complete. The Zend Framework, like any component library, should be environment-neutral wherever possible. We are sure that require_once() works in all environments. You mentioned that autoload may not be compatible with environments that do bytecode caching. I don't know the answer to that, but certainly it deserves some testing before we adopt autoloading in the Zend Framework. Feel free to use spl_register_autoload() in your application that employs the Zend Framework if it works for you, but I would not be in favor of using autoload within ZF until we're sure it won't break in some people's environment. We must also be sure that it will give performance benefit that justifies this risk. Educated conjecture is not a good basis for making this design decision. We must run tests that show quantitatively where the performance bottleneck in Zend Framework lies, using a typical application as the test case. Then try the test again with the code modified to use autoload. Quantify how much improvement you get by using autoload. Then compare this solution to the improvement given by other potential solutions, for instance bytecode caching. If the bottleneck in Zend Framework is revealed through testing to be unrelated to loading classes, then autoload won't offer much benefit. If that is the case, I would favor using the most clear coding practice, which is require_once(). Regards, Bill Karwin
