CodeFeast

For an overview of autoloading in general, please see my previous article

Much fuss is made over the performance penalties of using PHP’s magic autoloading functionality. While I believe that it reduces overall project complexity and increases productivity, there are some very high-traffic projects I’ve overseen where the performance overhead becomes noticeable. This is particularly true for page requests that are already sensitive to delays, such as AJAX or REST requests. In this article, I’d like to showcase a couple of options for mitigating (and even eliminating) autoloader performance penalties.

Please note that all code examples in this article are strictly for illustrative purposes, and are not at all ready for production sites. These concepts should serve as starting points to implement your own high performance autoloaders

The Problem

While autoload is a godsend for managing large projects, you do incur a small performance penalty for its use. This overhead occurs primarily because:

• Most autoloader methods search through the include path
• Most autoloader methods include files using relative paths
• PHP must devote execution time to Just In Time load each class. This magic comes at a price.

If this process occurs a few dozen times per request, and requests are popping in around 10/second, you might find yourself in a boring meeting discussing how the hell your team can decrease latency.

Step 1: Include Patch Caching

By and large, the content of include directories for production projects does not change. If a class file was found during the last request, why search for it again during the current one?

Rather than simply calling include() (or require() ) from your autoloading methods, do a little digging to discover the absolute path of the file for a particular class. This will be an expensive operation, but it need only be performed once. Each subsequent request can simply result in the direct inclusion of the correct file, rather than a hunt through the include_path. An example:

Using this autoloader class, the actual search for the file is only performed the first time a file is requested. Furthermore, performance is enhanced by the calling of require() rather than require_once(), and by calling it with the absolute path to the file requested.

Step 2: Anticipatory Autoloading

So, you’ve implemented path caching in your autoloaders, but your users are still complaining that their annoying popups aren’t loading fast enough? Let’s figure out how to keep the convenience, but completely eliminate calls to autoload.

Much like the include_path, the specific classes loaded for each section of your application are unlikely to change from request to request. If we can find a unique identifier that will partition our apps into segments (such as the URL), we can simply have our autoloader remember what files it had to load from the last request, and skip the autoloader overhead all together.

Let’s start with our previous example, and add some enhancements:

And now we’ve rid ourselves of autoload’s performance overhead without sacrificing any of its convenience.

This class has little effect on the initial, uncached request to an app segment, but really shines on subsequent requests.

Since this class remembers what it autoloaded, it can eliminate itself all together and bring what it will need in as simple includes. Best of all, it still has autoload functionality in the unlikely event that the required classes change between requests.

Since we’ve chosen to segment our app by URL, I’ll use “index.php” as an example. You could also easily segment by module, controller, or action.
When the first request is made for the location “index.php”:

1. The autoloader is woken up and restores its cache files
2. Every class that is needed for index.php will be autoloaded as usual
3. The autoloader will remember everything it had to autoload for “index.php”

Now, when the second request is made for this same location, this happens:

1. The autoloader is woken up and restores its cache files
2. Every class that it had to autoload last time is immediately included
3. The people rejoice

Security Note

Do not store the autoloader cache files in /tmp, or any other world writable area. The last thing any of us needs is some little weenus having the ability to arbitrarily load include files on our server. Also, you really should perform some sanity checks on the files you’re including in your autoloaders.

Conclusion

I hope these crude classes effectively illustrate that you needn’t suffer autoloader overhead with every request. I should also note that I don’t advocate the use of steroids. Sure, you look great on the beach, but they shrink your giblets.

It Seemed Like a Good Idea at the Time

I’ve recently noticed a few articles advocating the use of PHP’s __autoload function to manage project includes. I’m sure these authors have good intentions, but the __autoload functionality became outdated before anyone really even started using it.

The __autoload function was introduced way back in PHP5 as a means to dynamically load class files as you need them. It was definitely a step in the right direction, and using it was a good design choice for all but the smallest object-oriented projects.

In case you missed it, __autoload replaced the need to call individual includes for each external class file. For instance, your only option for loading a file “KrunkTastic.php” which contains the “KrunkTastic” class definition used to look like this:

Clearly, this could get to be a big pain as your project grew. You were then faced with loading every class you’d ever need, or remembering to load them yourself every time you needed to get your krunk on. Both of these solutions sucked. Luckily, the PHP developers agreed, and gave birth to a good first draft solution.

Once a function called __autoload is defined, PHP will call it when it comes across a class definition it doesn’t know about. This gives you a chance to load the class file before PHP tries to access it. Consider the previous example:

When the PHP5 parser gets to the line that instantiates a new object of type “KrunkTastic”, it realizes that no class by that name has been declared. It does, however, notice that we’ve defined a function called “__autoload”. PHP then calls our __autoload function, passing the name of the unknown class as our “$className” parameter. This gives us one last change to include the proper class file. That’s right, PHP4, you suck.

Abomination!

This all seems pretty slick, but within this architecture lurks a deep and insidious evil. Since __autoload is declared as a global function with a fixed name, it can only be declared once. This severely limits the developers of third-party toolkits and libraries in their use of this functionality. If you integrate libraries into your application that have already declared an __autoload function, you can’t re-declare it for your own code.

This means that, while it’s a perfectly adequate solution for smaller projects, __autoload is pretty crappy for the big projects that need it the most. The PHP team, who would not stand for such a bummer, then crafted a much more workable solution.

Enter spl_autoload

PHP 5.1.2 introduced the spl_autoload family of functions. This gave developers the ability to switch from a single, global __autoload function to a global autoload stack of functions, registered using spl_autoload_register. An example:

It should be noted that as soon as you make a call to spl_autoload_register, any legacy __autoload function will be ignored. That’s what it deserves for being old and busted. If you really want to use it, you have to manually add it to the spl_autoloader stack with a call to spl_autoload_register(’__autoload’).

Conclusion

Using legacy autoloading via __autoload has been obsolesced by superior autoloader stacking, which offers much more flexibility, and interoperability with third-party libraries. Go forth and prosper, and stop loading your class files manually like a masochist. Unless you’re a masochist, in which case I respect your lifestyle choice.