Hello George, Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.php.net/rfc/core-autoloading > > The existing SPL autoloading functions would become aliases to the new Core > ones and will continue to work without any migrations needing to be > performed. >
Thanks to you and Dan for the RFC. I have two main questions about this: 1. What's the performance hit? 2. If the perf hit is measurable, is function autoloading worth it? aka what problem does it address? About the perf hit, I see that you put a lot of thought into minimizing it and that's sound. The way I see this feature be spread to userland is via composer of course. I foresee that composer will add a way for packages to declare function autoloading. This means that every application that uses composer will be impacted by the perf overhead eventually (aka the case of "programs that do not have a function autoloader registered" mentioned in the RFC won't happen in practice.) In e.g. https://github.com/php/php-src/pull/6627#issuecomment-773922448, Dmitry explains that adding inheritance cache to PHP provided a 8% perf benefit when running a demo app. I would like to see a similar benchmark with function autoloading enabled. https://github.com/phpbenchmarks/ provides several demo apps so it could be a nice playground for running this. Then, depending on the resulting numbers, I anticipate several possible outcomes: - if the impact is really low, then all is fine and we can keep things as is; - otherwise, I'm also interested in this idea to scope function autoloading per namespace, so that the engine can filter ahead of calling any userland autoloaders; - if the overhead is still significant, could another idea be to load functions per namespace, where the engine would ensure to call function autoloaders only once per namespace? Even with the current proposal, I can easily anticipate that a common practice for package authors could be to put all functions in one file, and register a function autoloader that would require that file for any of the functions in it. Loading per namespace would fit this loading strategy. But before exploring this idea, let's get some numbers about the performance of the previous approaches. Then comes my second main question: what does this solve? To me, class autoloading is a performance feature. If we didn't care about performance, we would be fine with eagerly loading a bunch of classes as e.g. Java does. But because we run PHP mainly in short-lived request/response loops, loading just the few classes we need to serve a specific request provides the best performance. In recent versions of PHP, we may question this practice, since we now have a crazy good opcache. Of course, I'm not suggesting removing autoloading for classes. But if we do have that crazy good opcache, what do we need function autoloading for? The current way for package authors to declare classes is via composer "files <https://getcomposer.org/doc/04-schema.md#files>" entry. One could argue in the past that this adds needless "require" on the hotpath. But if they cost nothing thanks to recent opcache improvements, we don't need to care, do we? At least, we need to compare both approaches, because if the main argument for adding function autoloading is lazy-loading of function implementations, then it must be faster than eager-loading. This circles back to my previous question, so we'd really need a thorough perf analysis IMHO. Nicolas
