[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal
WordPress Trac
noreply at wordpress.org
Fri Sep 16 06:27:09 UTC 2016
#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
More information about the wp-trac
mailing list