[RFC] Autoloader Classmap

4 years ago by Mark Randall — view source — reply

unread

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

4 years ago by Mark Randall — view source — reply

unread

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.

4 years ago by Stephen Reay — view source — reply

unread

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.

--

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

4 years ago by drealecs@gmail.com — view source — reply

unread

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.

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

4 years ago by Matt Fonda — view source — reply

unread

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

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.

--

To unsubscribe, visit: https://www.php.net/unsub.php

4 years ago by Jordi Boggiano — view source — reply

unread

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

4 years ago by Nikita Popov — view source — reply

unread

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

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