[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

[WordPress Trac]

#36335: Next generation: core autoloader proposal
-----------------------------+------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by schlessera):

 Replying to [comment:194 TJNowell]:
 > While I would prefer a composer autoloader, I think that there are
 points that need addressing that have been raised by others:
 >
 >  - What performance improvements can autoloading provide?

 An autoloader comes with an inherent overhead, and when you load 100% of
 your classes, the autoloader will be slower than direct requires. When a
 code base is optimized for autoloading, it will most certainly run faster
 and consume less memory.

 In a very simple performance test (http://blog.ircmaxell.com/2012/07/is-
 autoloading-good-solution.html), Anthony Ferrara found out that, '''for
 empty classes''',  the autoloader is faster once you're using 75% or less
 of the classes. The heavier your classes are (think `WP_Query`), the
 higher that percentage is. For the WP code, not loading a handful of
 classes will probably have the autoloader pull ahead in terms of
 performance.

 >  - What problem does this solve?

 - Only load classes when effectively needed (saves processing time and
 memory).
 - Loading order is irrelevant (makes some procedural logic unnecessary).
 - You don't need knowledge about the filesystem layout (of your code, as
 well as of your dependencies).
 - As such, you are free to reorganize your file layout as you see fit
 without breaking the code.

 > So far, Mike is the main opponent of a Composer based autoloader, but if
 I read correctly he has no opposition to an autoloader, just the Composer
 variety. This means there is still work that can be done without
 addressing that.

 > Mike has indicated he wanted to work on an autoloader proof of concept
 but didn't have time in that week. Now that time has passed, I'm curious
 to see what he's devised. We also have the composer autoloader, and I
 think both can be used to test and measure performance improvements so
 that autoloading is an easier sell for those still sceptical

 As we don't have an autoloader yet, the code base is not optimized for the
 use of an autoloader either. This makes performance benchmarks completely
 pointless, as the result is probably something along the lines of
 "performance without autoloader + autoloader overhead". The end result
 we're after is not to have an autoloader be included, but to have a code
 base that makes proper use of an autoloader. That is what would need to be
 benchmarked, not "old code + autoloader class".

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36335#comment:196>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform