[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:220 MikeSchinkel]:
 > That said I am honestly '''I am not seeing conclusive difference in
 performance between any of the three options'''. The problem is the timing
 numbers jump around all over the place and also seem dependent on how long
 since the last request of the same page, so without a scripted test any
 data I generate would likely not be valid.

 I suspected so. The issue is that the code is still basically loaded
 procedurally, only through the additional detour of an autoloader. As long
 as we don't do the work of actively optimizing for loading on-demand,
 autoloader benchmarks will be arbitrary and pretty meaningless. The only
 think you can compare at this point is the actual implementations of the
 generated autoloaders, which is an exercise in futility, as both can be
 freely adapted to match each other.

 > '''However, I am seeing a difference in memory usage''': Trunk was the
 worst, Custom was the best, and Composer was almost as good as Custom.
 '''''Best I can tell''''' Custom used between `5%` and `10%` less memory,
 and using Custom is about `1%` less memory than with Composer.

 The difference in memory usage probably comes from the fact that your
 approach has relative paths in the classmap, and the Composer one has
 absolute paths in the classmap. Again, this can be changed into whatever
 we want for both, so that point is moot as well.

 A note regarding your comparison: the one currently merged into the
 feature project GitHub repo has excluded most of the third-party/legacy
 classes for now:
 https://github.com/staylor/develop.wordpress/blob/autoloader/src/composer.json#L49-L68

 And I would once again make you aware that you're now slowly building,
 feature-for-feature, a replica of the Composer Generator, but without the
 unit tests, without the community and maturity, and without the
 standardized configuration. This last point is very important, as it
 allows to reconcile several autoloaders into a single coherent, optimized
 autoloader. I still fail to see what the exact '''advantage''' is of
 reinventing the wheel...

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