Make WordPress Core

Opened 4 weeks ago

Last modified 12 days ago

#60414 new enhancement

Core PHP autoloader proposal

Reported by: aristath's profile aristath Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: General Keywords: has-patch has-unit-tests
Focuses: performance, sustainability Cc:

Description

Using a PHP autoloader can improve performance, and can be seen as a first step towards modernizing the WP codebase in the future.

This ticket is a continuation of the discussion on #36335
The discussion in the original ticket was derailed many times, so this fresh ticket is an opportunity to discuss the Core proposal submitted on the Make blog

Change History (6)

This ticket was mentioned in PR #3470 on WordPress/wordpress-develop by @aristath.


4 weeks ago
#1

  • Keywords has-patch has-unit-tests added

#2 follow-up: @justlevine
4 weeks ago

Love this!

@aristath can you clarify how (if at all) this relates to the Autoload class used by Requests])? You mentioned in the Proposal that an API is outside of the scope, and I'm assuming that since Requests is also intended to be consumed outside of WP contexts that it'l continue to maintain it's own implementation, and I'm not seeing anything directly related in the diff,

(Don't want to derail this by another decade by bringing up Composer again - so for people coming here directly and not from the Make post, let's hold on to this:

This is the first step towards modernizing the WP codebase. Though in itself it may appear like a marginal (but still very worthy) performance improvement, it opens the door to more improvements in the future of WordPress without any backwards-compatibility concerns.

and this followup comment)

#3 in reply to: ↑ 2 @aristath
4 weeks ago

Replying to justlevine:

@aristath can you clarify how (if at all) this relates to the Autoload class used by Requests])? You mentioned in the Proposal that an API is outside of the scope, and I'm assuming that since Requests is also intended to be consumed outside of WP contexts that it'l continue to maintain it's own implementation, and I'm not seeing anything directly related in the diff,

Check out the WP_Autoload::register_external_bundled() method.
It registers the autoloaders from external libraries inside the Core autoloader. Hard includes/requires for these were then removed from the rest of the WP codebase, and the Core autoloader handles them 👍

@aristath commented on PR #3470:


3 weeks ago
#4

Adding some numbers from tests ran today.

## Included files

Adding this snippet in mu-plugins/snippets.php:

<?php
add_action( 'shutdown', function() {
        var_dump( count( get_included_files() ) );
} );

I got the following numbers:
| | Trunk | Autoload | Diff

Front 442 347 -95 files (-21.5%)
Dashboard 479 370 -109 files (-22.7%)

I only checked the frontpage and the main dashboard page, so these numbers will differ depending on the context. Some pages will have smaller differences, others will have larger. I expect that REST-API endpoints will have a significantly larger benefit, but I don't know exactly how to measure that.

## Memory usage.

Tested using the Debug Bar community plugin. Numbers in Kb
| | Trunk | Autoload | Diff

Front 4327 4329 0.04%
Dashboard 4074 4078 0.09%

This shows that the autoloader implementation currently uses 0.04-0.09% more memory. I don't know if that is because I have XDebug running (which admittedly is a performance hog), these numbers contradict previous tests both by @spacedmonkey in https://github.com/WordPress/wordpress-develop/pull/3470#issuecomment-1490083546 as well as previous tests of mine. Worth examining what changed these past few months.

## Time

Tested using XDebug profiling. Report built using webgrind.
These numbers are the average of 5 runs because XDebug-profiling produces rather inconsistent numbers.

Trunk Autoload Diff
Front 392ms 377ms -3.82%
Dashboard 317ms 295ms -6.94%

The above tests are somewhat basic.
If someone else has the ability and/or ability to run some more detailed tests to get more consistent numbers, it would be greatly appreciated 👍

@bartj commented on PR #3470:


2 weeks ago
#5

I have played a little with benchmarking, doing 100 sequential requests to each endpoint. The results should be more consistent, but I'm not sure what is the reason for quite large variance (look at the standard derivation value for timing).

Benchmarking was running against PHP 8.1 with nginx server. Profiling data comes from xhprof (slightly better than xDebug and provides actual memory usage info).

### Average Run Times (mean) / (median) / (stddev)

trunk autoload Percentage Diff
admin 125.79ms / 121.37ms / ±22.38 125.02ms / 121.66ms / ±17.82 -0.62%
front 228.13ms / 223.95ms / ±13.45 230.23ms / 224.68ms / ±16.14 0.92%
rest 91.55ms / 89.32ms / ±13.23 87.20ms / 86.25ms / ±5.17 -4.75%

### Average Memory Usage (mean) / (median) / (stddev)

trunk autoload Percentage Diff
admin 6.04M / 6.04M / ±0.04 6.23M / 6.23M / ±0.00 3.08%
front 6.66M / 6.66M / ±0.00 6.69M / 6.69M / ±0.00 0.49%
rest 5.68M / 5.68M / ±0.00 5.71M / 5.71M / ±0.00 0.5%

I've left notes on how my benchmark was conducted, along with collected results in repository: https://github.com/bart-jaskulski/wordpress-benchmark

This ticket was mentioned in Slack in #core by jorbin. View the logs.


12 days ago

Note: See TracTickets for help on using tickets.