Composer interest in PHP 8.1 accelerated include resolving

[markrandall]

Greetings,

I am currently working on a PHP RFC for an accelerated autoload classmap, this RFC adds a new mechanism called autoload_set_classmap() which accepts an associative array of classname => file paths, and acts as an internal first-stage autoloader.

The change offers a 5% improvement in performance vs hitting composer's existing userland function and performing the lookup there (testing exclusively the autoload mechanism). As composer is the de-facto autoloader, the general consensus is that it would only be worth adding if Composer itself could take advantage of it.

The necessary change would be to call autoload_set_classmap as part of the existing autoloader registration, feeding in the existing static autoload classmap, with one exception, class names must be stored lowercase (as per internal class naming). This would be something that would be necessary to do as part of the dump autoload step.

Therefore, I ask would composer have an interest in using such a function should it be accepted for 8.1.

[stof]

To me, this makes perfect sense.

[Seldaek]

I have emailed you twice on the internals list about this:

https://externals.io/message/113545#113984
and previously https://externals.io/message/113576#113562

I still haven't seen an answer from you about the concerns I raised regarding having multiple autoloaders in one process.

[stof]

@markrandall if the various composer plugins ship their own Composer autoloaders (due to being installed in older ways not managing autoloading for them), my proposal would probably cover it already

[Seldaek]

@stof right that makes sense 👍🏻

@markrandall most likely for wordpress this would not optimize much, but tbh the rate of Composer usage in WordPress is anyway unknown, most likely fairly low. Some plugins use it internally but I don't know exactly how wide-spread that is. WP is also mostly deployed without build step, so it doesn't really lend itself well to a classmap autoloader to begin with, and it's IMO not the main target for such a performance optimization.

[stof]

@markrandall and yes, for my proposal to work, the only change needed for the RFC is to allow calling it multiple times, with the "last one wins" semantic. Everything else is on the composer side when using it.

[markrandall]

@Seldaek @stof If everyone is in agreement, I'm happy to make that change to the RFC.

[Seldaek]

Sounds good! Thanks both for the discussion here, hopefully this leads to some meaningful improvement down the line :)