Re: function autoloading v4 RFC

On Wed, Aug 21, 2024, at 01:53, Matthew Weier O'Phinney wrote: > > > On Tue, Aug 20, 2024, 4:56 PM Rob Landers <rob@bottled.codes> wrote: >> __ >> >> >> On Tue, Aug 20, 2024, at 18:07, Rob Landers wrote: >>> On Tue, Aug 20, 2024, at 08:50, Rowan Tommins [IMSoP] wrote: >>>> >>>> >>>> On 20 August 2024 00:21:22 BST, Rob Landers <rob@bottled.codes> wrote: >>>> > >>>> >I assume you are worried about something like this passing test? >>>> > >>>> >--TEST-- >>>> >show called only once >>>> >--FILE-- >>>> ><?php >>>> > >>>> >namespace test; >>>> > >>>> >spl_autoload_register(function($name) { >>>> > echo "name=$name\n"; >>>> >}, true, false, SPL_AUTOLOAD_FUNCTION); >>>> > >>>> >echo strlen('foo'); >>>> >echo strlen('bar'); >>>> >echo strlen('baz'); >>>> >?> >>>> >--EXPECT-- >>>> >name=test\strlen >>>> >333 >>>> > >>>> >In my RFC, I mention it is called exactly once. >>>> >>>> >>>> I haven't looked at the PR, only the RFC, and I did not see this very >>>> important detail explained anywhere. The only thing I can see is this rather ambiguous sentence: >>>> >>>> > The function autoloader will not be called again. >>>> >>>> That could mean not called again for the current call (compared with proposals that >>>> call it a second time with the unequalled name); it could mean not called again for the current line >>>> of code (based on the current caching behaviour); or never called again for that combination of >>>> namespace and name; or possibly, never called again for that combination of namespace, name, and >>>> callback function. >>>> >>>> That's not a small detail of the implementation, it's a really >>>> fundamental difference from previous proposals. >>>> >>>> So I would like to repeat my first response to your RFC: that it should sound more >>>> time explaining your approach to the multiple lookup problem. >>>> >>>> Regards, >>>> Rowan Tommins >>>> [IMSoP] >>>> >>> >>> Thanks Rowan, >>> >>> That's a fair critique. >>> >>> I expect some of the wording will be more clear once I write out the documentation -- >>> even if it isn't used directly, I tend to write out documentation to force myself to reconcile >>> the code with the plan, find logic bugs, perform larger scale tests, and create tests to verify >>> assertions in the documentation. From there, I'll update the plan or code to get everything to >>> match and spend some time on clarity. It's the hardest part, IMHO, as it requires diligently >>> ensuring everything is correct. In other words, writing the documentation makes it feel like a >>> "real thing" and it triggers what small amount of perfectionism I have. >>> >>> — Rob >> >> I have an experimental library that I use for testing these kinds of things. There are >> aspects of it that I could work with to make use of function autoloading. Thus, I did so and >> benchmarked the performance of unit tests. The unit testing library makes a ton of "unqualified >> function calls". >> >> I spent some time working on two autoloaders: >> 1. A naive autoloader: parses out the file to load, checks if it exists, and then requires >> the file. >> 2. An optimized autoloader: only cares about the namespace it has registered. All others >> are an instant return. > > Not to sound flippant, but you do realize that composer does a lot of optimizations just like > this, right? > > PSR-4 exists in large part due to a realization that better optimizations were possible when > you mapped namespaces to source code directories. And Composer takes it a step further when you have > it create an optimized loader, because then it maps classes directly to the files that provide them, > preventing I/O up to the point that a require is performed. > > My point is that this is why folks have been suggesting that this is a solved problem. Globally > qualify functions, and you get immediate performance benefits due to removal of the need to look up > via the namespace first. Most CS tools will even add the imports or qualifiers for you, and you can > have your IDE or editor configured to do it as well. > > > I wouldn't spend your time on this facet. There are people worried about the performance issues with adding function autoloading (due to having to look up functions at every call, for unqualified global). And yes, Composer does this for classes, but it doesn't (yet) do it for functions, meaning it has to be done manually. So, my goal here is to either (1), convince people it is a non-issue, or (2) show that it is an issue and we should take steps to fix it (such as flipping the order functions are looked up, or whatever). Now ... on to WordPress! WordPress makes very few unqualified function calls; however, it can benefit from function autoloading since it uses a number of functions files and such. I had to patch it for this, remove all the require's and generate a function map for the autoloader. I ran three tests: 1. Vanilla WordPress with no changes 2. Vanilla WordPress with no changes, but an autoloader that just returned 3. Modified WordPress to take full advantage of function autoloading Graphs are coming in the RFC, but it looks like WordPress would gain a 1-3% speed improvement if they used function autoloading. If anyone knows of any other function-heavy projects, I'd love to throw them at this as well. Tomorrow I want to take a look at some of the projects Ilija looked into that use a number of unqualified functions and see if they will take a major performance hit by having function autoloading enabled. — Rob