X Autoload: Performance
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