For performance, the goal is:

• As a minimum, to be competitive with existing solutions (currently looking at symfony and Composer)
• To be 90% competitive with the theoretical optimum. This means, we may accept to be 10% slower than theoretically possible, if this can buy us architectural quality.

Optimize our loops

Both the Symfony UniversalClassLoader and the Composer ClassLoader have a minor performance flaw, if set up with too many namespaces:

For every direct lookup, they loop over the entire array of registered namespaces.

If we register a namespace for every Drupal module. this can be quite a lot.

The X Autoload class loader does not do this. Instead, it loops over all partial namespaces or prefixes of the given class, and does an array lookup for each.

Adding a cache layer

The idea is to add the same cache mechanisms as we can find in existing solutions. That is:

• symfony's apc cache. (that's a kind of lazy caching)
• Composer's class map. For us, we probably only want to map the most frequently used classes, so we do not have a huge array to load in every request.

Both of these can be easily added as plug-on components, so they can be combined with more than one ClassFinder implementation.

In Composer, the idea is to pre-fill the map with a scan. We will probably lazy-fill the map based on a statistics model. Every tenth request gets a statistics-enabled class loader, to find out which classes are requested the most often.

Overhead due to composition over inheritance?

Compared to Symfony and Composer, we use a lot more composition. This may or may not add performance overhead, but is probably negligible compared to the cost of file_exists() and finally including the file.

Eliminate the need for custom autoloaders

Yes, any additional autoloader added with spl_autoload_register() would slow us down, if these are considered for every class.

If these custom loaders are instead registered as a plugin to xautoload, and only for a specific prefix or n