# [RFC] Autoloader Classmap

- Thread: https://externals.io/message/113545
- Original archive: https://news-web.php.net/php.internals/113545
- Started by Mark Randall on 2021-03-15T17:41:38+00:00
- Messages: 7
- RFC: Autoload Classmap (Inactive) — https://externals.io/rfc/autoload_classmap.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #113545 — Mark Randall — 2021-03-15T17:41:38+00:00

URL: https://externals.io/message/113545#113545

Hi Internals,

I would like to propose the addition of a new mechanism of autoloading 
classes - a classmap that will be consulted prior to checking the 
spl_autoload_register'd callbacks.

https://wiki.php.net/rfc/autoload_classmap

Mark Randall
marandall@php.net

---

## #113972 — Mark Randall — 2021-04-05T22:05:02+00:00

URL: https://externals.io/message/113545#113972 · In reply to: #113545

> I would like to propose the addition of a new mechanism of autoloading 
> classes - a classmap that will be consulted prior to checking the 
> spl_autoload_register'd callbacks.
> 
> https://wiki.php.net/rfc/autoload_classmap

Does anyone else have any more feedback on this? If not I plan on 
opening voting in a couple of weeks or so.

The tl;dr:

* Autoloading is one of the routines called most frequently in any request.

* It's a very minor boost in autoloading performance, around 5% vs 
invoking a userland function. This will easily be swamped by any IO and 
invalidated entirely by preloading.

* I expect 99.9999% of users will never know it exists, and it will 
instead just be an option for tools like composer that will provide a 
small transparent boost.

* It provides a very minor benefit to debugging as you get to skip over 
the autoloading frames which so very often come up during a request.

---

## #113975 — Stephen Reay — 2021-04-06T05:11:05+00:00

URL: https://externals.io/message/113545#113975 · In reply to: #113545

> 
> 
> 
> > […]
> 
> Does anyone else have any more feedback on this? If not I plan on opening voting in a couple of weeks or so.
> 
> The tl;dr:
> 
> * Autoloading is one of the routines called most frequently in any request.
> 
> * It's a very minor boost in autoloading performance, around 5% vs invoking a userland function. This will easily be swamped by any IO and invalidated entirely by preloading.
> 
> * I expect 99.9999% of users will never know it exists, and it will instead just be an option for tools like composer that will provide a small transparent boost.
> 
> * It provides a very minor benefit to debugging as you get to skip over the autoloading frames which so very often come up during a request.
> 
> 
> -- 
> 
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Hi Mark,

Just to clarify something - wouldn't the loader use ‘require’ behaviour, not ‘require_once’ behaviour? If you’re hitting the autoloader, that means the class in the file you’re about to load isn’t defined yet, which means the file hasn’t been loaded already. Using require_once you’d be doing a check if the file has loaded in a scenario where it would have never been loaded anyway.



Cheers

Stephen

---

## #113976 — drealecs@gmail.com — 2021-04-06T08:01:33+00:00

URL: https://externals.io/message/113545#113976

> 
> > […]
>
> Does anyone else have any more feedback on this? If not I plan on
> opening voting in a couple of weeks or so.
>


   - It's not clear from the RFC if the `spl_autoload_call` will use the
   classmap or not. I assume yes but maybe it's good to mention that.
   - There is a mention about another "independent RFC" but I can't seem to
   find any draft of it or other reference. Maybe add some more links and
   clarify when it is expected to be filled and by who.
   - It was previously discussed but it's still not clear why the key
   should be lowercase.
      - As far as I understand, when the class autoloading is triggered,
      the classname is available with it's requested case so that is
not an issue.
      - It is inconsistent with how `autoload_register` callable works.
      - I would like to have things like
      autoload_set_classmap([ClassToBeLoaded::class =>
      '/specific/path/for/class.php]) without adding an extra `strtolower`
      wrapping call.
      - Is there a performance benefit of having all classes with lowercase?
      - If a class autoloading is triggered with the wrong case (due to a
      typing error), I would very much like to fallback to classic autoloaders
      and fail so that I can possibly find the issue faster.
   - Related to"Trigger a TypeError if the key's associated value is not a
   string.", shouldn't we validate the value when setting up the function.
   Having a TypeError when autoloading happens signaling an invalid
   configuration sounds a bit weird.
   - Does the extra step to check the classmap also increase time if the
   class is not found? If most of the classes are loaded using classic
   autoloaders, will there be an impact from having some classes defined for
   the classmap autoloader?
   - How was the test that showed the 5% run? Was there any IO involved
   during the classloading? How was the opcache configured? There are some
   times mentioned there but it's not clear the unit of measure.
   - I understood that in real life the 5% is only out of the 0.1 - 1% that
   is classloading out of a script's runtime. That would mean an 0.005 to
   0.05% performance increase. It's unclear to me how much of a script's time
   the autoloading takes. Maybe you can clear that out if you counted for a
   normal application run, like a hello world from symfony. I understand that
   there will be nothing visible but maybe it's good to mention that, just to
   have clear expectations.
   - Maybe you can give a sample code for when the autoload_set_classmap
   needs to be used from two different contexts/modules that are not aware
   about the others. I would expect something like:
      - `autoload_set_classmap(autoload_get_classmap() + $moduleClassMap)`,
      not overriding previously set map values, if duplicates

Regards,
Alex

---

## #113980 — Matt Fonda — 2021-04-06T18:02:14+00:00

URL: https://externals.io/message/113545#113980

Hi Mark,

I'm a fan of adding an easy and performant way to implement classmap-based
autolading, but weary of adding yet another way to autoload. If it would be
possible to do so without negating the performance improvements, I'd
suggest having this work in conjunction with the existing
spl_autoload_register rather than introducing two different ways to specify
autoloaders. I.e., usage would look like:

spl_autoload_register(autoload_classmap($mapping));

Cheers,
--Matthew



> 
> > […]
>
> Does anyone else have any more feedback on this? If not I plan on
> opening voting in a couple of weeks or so.
>
> The tl;dr:
>
> * Autoloading is one of the routines called most frequently in any request.
>
> * It's a very minor boost in autoloading performance, around 5% vs
> invoking a userland function. This will easily be swamped by any IO and
> invalidated entirely by preloading.
>
> * I expect 99.9999% of users will never know it exists, and it will
> instead just be an option for tools like composer that will provide a
> small transparent boost.
>
> * It provides a very minor benefit to debugging as you get to skip over
> the autoloading frames which so very often come up during a request.
>
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

---

## #113984 — Jordi Boggiano — 2021-04-07T09:05:36+00:00

URL: https://externals.io/message/113545#113984

Hi Mark,


>
> * I expect 99.9999% of users will never know it exists, and it will 
> instead just be an option for tools like composer that will provide a 
> small transparent boost.
>
I wrote this as feedback in your early round (I don't think you 
answered), and IMO it still stands:

//

The proposed API should really support
multiple maps. Composer has a  prepend-autoloader option which controls
whether the generated autoloader will be prepended or appended when
spl_autoload_register is called. This is required in some cases where
multiple autoloaders coexist. So the ability to add multiple maps,
including optionally prepending them would be a must IMO. The ability to
remove an autoloader and its associated classmap would also be very
welcome so one can unregister things cleanly.

So taking the above in consideration, and keeping consistency with
existing spl_* functions in mind, I would propose an API more like:

     autoload_register_classmap(array $map, bool $prepend = false)
     autoload_unregister_classmap(array $map)

//

Given the current API proposal, I think I would vote no, because I do 
not know how I'd even implement this in Composer without making a mess 
in case multiple autoloaders co-exist (which one can not know about at 
autoload generation time). We'd have to perhaps set the classmap on the 
first autoloader, and if a second autoloader gets created it'd wipe the 
classmap entirely and skip the optimization for safety because it 
becomes unmanageable otherwise.


> * It provides a very minor benefit to debugging as you get to skip 
> over the autoloading frames which so very often come up during a request.
>
In development environment we do not recommend using an optimized 
autoloader as it slows down updates/installs and doesn't bring a ton of 
perf benefit, so this argument isn't that strong.

Best,
Jordi

---

## #114069 — Nikita Popov — 2021-04-19T09:39:30+00:00

URL: https://externals.io/message/113545#114069 · In reply to: #113984

> Hi Mark,
>
> 
> > […]
> I wrote this as feedback in your early round (I don't think you
> answered), and IMO it still stands:
>
> //
>
> The proposed API should really support
> multiple maps. Composer has a  prepend-autoloader option which controls
> whether the generated autoloader will be prepended or appended when
> spl_autoload_register is called. This is required in some cases where
> multiple autoloaders coexist. So the ability to add multiple maps,
> including optionally prepending them would be a must IMO. The ability to
> remove an autoloader and its associated classmap would also be very
> welcome so one can unregister things cleanly.
>
> So taking the above in consideration, and keeping consistency with
> existing spl_* functions in mind, I would propose an API more like:
>
>      autoload_register_classmap(array $map, bool $prepend = false)
>      autoload_unregister_classmap(array $map)
>
> //
>
> Given the current API proposal, I think I would vote no, because I do
> not know how I'd even implement this in Composer without making a mess
> in case multiple autoloaders co-exist (which one can not know about at
> autoload generation time). We'd have to perhaps set the classmap on the
> first autoloader, and if a second autoloader gets created it'd wipe the
> classmap entirely and skip the optimization for safety because it
> becomes unmanageable otherwise.
>
>
> > […]
> In development environment we do not recommend using an optimized
> autoloader as it slows down updates/installs and doesn't bring a ton of
> perf benefit, so this argument isn't that strong.
>
> Best,
> Jordi
>

I think this RFC really needs an implementation in composer (i.e. a
reviewed PR) before it can go to vote. It would be entirely pointless if
this were implemented, and it then turned out that composer couldn't
actually use it.

Nikita