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
