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.