Zend_Loader's autoloader has been deprecated in the upcoming Zend Framework version 1.8 and so you now get [an "autoload is deprecated"] notice if you use it.

The fix is simple - just change your call from the static registerAutoload method on the Zend_Loader library to a getInstance call on the new Zend_Loader_Autoloader. You can find out more information about this new component here.

In this article I will introduce you to Zend_Loader, a Zend Framework class used to automatically load other classes. Typically you would use include_once() or require_once() when you want to load a class but using Zend_Loader you don't have to.

He talks some about how it works, how to enable an disable it and how you can replace it with your own custom autoloader if you want. He gives an example of doing this, overriding the loader with a call to registerAutoload to register his autoloader class.

A disclaimer which I should have added to my last article would include that most of my pseudo benchmarks are very subjective and also way too basic. For example, our server setup is pretty comprehensive but we have to take everything into account in order to provide real benchmark. And when I write everything I mean CPU (cores), RAM, motherboard, HDD and so on. Maybe even the throughput of the network card -- if it's different.

This second post is an attempt to correct some of the sore points from the previous one. Here's a list:

• require/include(_once) and __autoload, or "Why is __autoload() 'better'?"
• Zend_Loader ERRATA
• Caching database results
• Zend_Db
• Zend Framework (what it currently lacks)

On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?

He uses a set of scripts he developed to compare the bytecode caches of the requests both with and without the caching turned on. He ran the tests on a PHP 5.2 and PHP 5.3 installs with the lower (better) numbers coming from the latter in requests per second. He highly recommends turning this caching on on your system if you haven't already.

Here's the list:

• PHP Accelerators : APC vs Zend vs XCache with Zend Framework - a comparison of three tools - APC, the Zend Framework components and the XCache tool
• Zend Framework Performance Zend_Loader - a specific look at benchmarks on the Zend_Loader component
• PHP Accelerators: The Missing Details - benchmark results (and code) showing results from testing on the Zend_Loader component
• Accelerators Revisited - a revisit to some of the benchmarks made previously (to change things based on user contributed comments)

When you use Zend_Loader your files are wrapped in conditional statements. These statements prevent APC and all other cache/accelerator programs to have problems properly caching your file. [...] Now here is the catch-22. Depending on the size of your application and how often different classes are used you can run into problems.

His result doesn't have much to do with the component, though - he points out that conditionals of any type can slow things down in an application and that "benchmarking is your friend".

When Stefan asked me to write about the Zend Framework, I decided I would avoid copy-able code, simply because it doesn't re-enforce good software design. [...] The following is a brief summary of 4 components in the Zend Framework: Zend_Loader, Zend_Log, Zend_Config and Zend_Registry.

For each of the four components, he looks at how they can be used (reason why), some good and bad things about them and he includes some pseudocode to show the format for its use.