Make WordPress Core

Opened 4 weeks ago

Last modified 5 days ago

#61112 reopened defect (bug)

Avoid re-constructing `WP_Theme_JSON` object from raw theme_json, instead use `WP_Theme_JSON` object inside `WP_Theme_JSON_data`

Reported by: thekt12's profile thekt12 Owned by: thekt12's profile thekt12
Milestone: 6.6 Priority: normal
Severity: normal Version:
Component: General Keywords: has-patch
Focuses: performance Cc:

Description

In many places, we have code similar to the following.

<?php
$theme_json   = apply_filters( 'wp_theme_json_data_default', new WP_Theme_JSON_Data( $config, 'default' ) );
$config       = $theme_json->get_data();
static::$core = new WP_Theme_JSON( $config, 'default' );

In the above code, we try to get the raw JSON using $theme_json->get_data() and then we try to build back WP_Theme_JSON object. Calling WP_Theme_JSON::_construct is expensive.

If we go a bit deeper we can see that class WP_Theme_JSON_Data has the following constructor

<?php

        public function __construct( $data = array(), $origin = 'theme' ) {
                $this->origin     = $origin;
                $this->theme_json = new WP_Theme_JSON( $data, $this->origin );
        }

By exposing the private attribute theme_json inside WP_Theme_JSON_Data via a public getter, we can avoid the expensive cyclic operation of creating the WP_Theme_JSON object from raw JSON data.

Some early tests PR 6271#issuecomment-2085982737 showed by doing this we can avoid 8 calls to WP_Theme_JSON::_construct which improves the overall server load time performance by ~2.5%.

Change History (18)

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


4 weeks ago
#1

Trac ticket: [Trac 61112
](https://core.trac.wordpress.org/ticket/61112)
Corresponding Guttenberg PR - https://github.com/WordPress/gutenberg/pull/61262

This was found while analysing https://core.trac.wordpress.org/ticket/59600, but it relates mostly https://core.trac.wordpress.org/ticket/57789

In this PR we are trying to avoid second call to new WP_Theme_JSON( $theme_json_data ); as the data can be obtained from WP_Theme_JSON_data class using just a line above by introducing a new public method. At the micro level call to WP_Theme_JSON constructor is expensive.

Interestingly, I can see this change also improved static calls. I wasn't expecting that as in my opinion static lines are only executed once, however, this has challenged my view about static calls and might be we need to be mindful of the performance even while using static.

The execution time of the wp_get_theme_data_custom_templates function on the home page of TT4 was evaluated. Each page had two calls to the function. The second call was static cached so it was significantly lower than the time for the first call.

{{{PHP
function wp_get_theme_data_custom_templates() {

Capture the start time
$startTime = microtime(true);
$data = WP_Theme_JSON_Resolver::get_theme_data( array(), array( 'with_supports' => false ) )->get_custom_templates();
Capture the end time
$endTime = microtime(true);

Calculate the script execution time
$executionTime = $endTime - $startTime;
echo "<pre>Execution Time of wp_get_theme_data_custom_templates: " . $executionTime . " seconds.</pre>";

return $data;

}
}}}`

The performance improvement was as noted below:
Before PR

Description Execution Time (seconds)
Run 1
Execution Time of wp_get_theme_data_custom_templates 0.0033679008483887
Execution Time of wp_get_theme_data_custom_templates 0.00087404251098633
Run 2
Execution Time of wp_get_theme_data_custom_templates 0.003180980682373
Execution Time of wp_get_theme_data_custom_templates 0.00077509880065918
Run 3
Execution Time of wp_get_theme_data_custom_templates 0.0039951801300049
Execution Time of wp_get_theme_data_custom_templates 0.00078392028808594
Run 4
Execution Time of wp_get_theme_data_custom_templates 0.0032379627227783
Execution Time of wp_get_theme_data_custom_templates 0.00077700614929199
Run 5
Execution Time of wp_get_theme_data_custom_templates 0.003154993057251
Execution Time of wp_get_theme_data_custom_templates 0.00075793266296387
Run 6
Execution Time of wp_get_theme_data_custom_templates 0.0032570362091064
Execution Time of wp_get_theme_data_custom_templates 0.00075292587280273

Mean of first call: 0.003366
Mean of static call: 0.000787

After PR

Description Execution Time (seconds)
Run 1
Execution Time of wp_get_theme_data_custom_templates 0.0030369758605957
Execution Time of wp_get_theme_data_custom_templates 0.0004730224609375
Run 2
Execution Time of wp_get_theme_data_custom_templates 0.0031139850616455
Execution Time of wp_get_theme_data_custom_templates 0.00047683715820312
Run 3
Execution Time of wp_get_theme_data_custom_templates 0.002918004989624
Execution Time of wp_get_theme_data_custom_templates 0.00047898292541504
Run 4
Execution Time of wp_get_theme_data_custom_templates 0.0026509761810303
Execution Time of wp_get_theme_data_custom_templates 0.00044488906860352
Run 5
Execution Time of wp_get_theme_data_custom_templates 0.0027339458465576
Execution Time of wp_get_theme_data_custom_templates 0.00045418739318848
Run 6
Execution Time of wp_get_theme_data_custom_templates 0.0029489994049072
Execution Time of wp_get_theme_data_custom_templates 0.00049400329589844

Mean of first call: 0.002900
Mean of static call: 0.000470

#2 @joemcgill
4 weeks ago

  • Milestone changed from Awaiting Review to 6.6
  • Owner set to thekt12
  • Status changed from new to assigned

Thanks, @thekt12. I've added this to the 6.6 milestone and we can wait for the https://github.com/WordPress/gutenberg/pull/61262 to land before porting the change here.

@oandregal commented on PR #6271:


4 weeks ago
#3

Oh, by the way. It'd be nice if this change would have been done first in the Gutenberg codebase. The value that provides is immense to all of us, including easier synchronization and quick feedback from Gutenberg users if we've missed something. I have nothing against merging it in wordpress-develop first, though I'd kindly ask that the authors port the same PR to Gutenberg. Until we figure out something better, this is what we collectively have and need to care for.

@thekt12 commented on PR #6271:


4 weeks ago
#4

Oh, by the way. It'd be nice if this change would have been done first in the Gutenberg codebase. The value that provides is immense to all of us, including easier synchronization and quick feedback from Gutenberg users if we've missed something. I have nothing against merging it in wordpress-develop first, though I'd kindly ask that the authors port the same PR to Gutenberg. Until we figure out something better, this is what we collectively have and need to care for.

Thank you @oandregal for your feedback. We clearly understand your feedback about Gutenberg first approach, hence we have already created a PR for Gutenberg (link in description of this PR). Once it's tested and approved on Gutenberg we can then plan to merge it for the core.

@oandregal commented on PR #6271:


4 weeks ago
#5

https://github.com/WordPress/gutenberg/pull/61262

Thank you so much 🙏 I approved the Gutenberg PR.

By reviewing the Gutenberg PR I noticed that the core code is missing a check: see https://github.com/WordPress/wordpress-develop/pull/6271#discussion_r1589940324 and https://github.com/WordPress/gutenberg/pull/61262/files#r1589940214. I don't know why they have differed but that check is important and we should consolidate both codebases.

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-performance by thekt12. View the logs.


8 days ago

This ticket was mentioned in Slack in #core-performance by mukeshpanchal27. View the logs.


7 days ago

#9 @joemcgill
7 days ago

  • Keywords commit added

I've reached out in the Gutenberg repo about merging the related PR there, but intend to commit this here before the Beta 1 cutoff.

#10 @joemcgill
5 days ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 58185:

Editor: Remove additional calls to WP_Theme_JSON::_construct.

This improves performance of the WP_Theme_JSON_Resolver class by avoiding redundant construction of WP_Theme_JSON objects for each origin.

Props thekt12, joemcgill, swissspidy, audrasjb, oandregal.
Fixes #61112.

#12 @ryelle
5 days ago

  • Keywords has-patch commit removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

I think this is going to cause trouble for anyone running WP trunk + Gutenberg— I've just updated a site and it triggered a number of Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() errors.

That should be fixed when the corresponding GB code is updated (I see it was done in this PR), but that won't be released for another two weeks, I believe. Is there anything that can be done in the meantime?

(I'm reopening this for that reason, but let me know if I should take this elsewhere)

#13 @thekt12
5 days ago

@ryelle Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() is a bit strange error to occur. If you see the introduction of WP_Theme_JSON_Data_Gutenberg::get_theme_json() method and related changes occur in a single PR(PR). Can you check if changes to https://github.com/WordPress/gutenberg/blob/trunk/lib/class-wp-theme-json-data-gutenberg.php are reflected properly on that site, I can see the method on trunk?

Also, there is no fear of conflict with the core as class names are different in both places. If WP trunk + Gutenberg are active, the Gutenberg class is given priority over the core class.

#14 @thekt12
5 days ago

@ryelle I think I understand the scenario now. If I understand correctly, you have your core updated to these changes, but your Gutenberg plugin is still old.
This error in any scenario shouldn't occur given we have different class names for the same reason.

#15 @dd32
5 days ago

@thekt12 This would be with WordPress Trunk + Latest Gutenberg (Which is 18.4). The PR in Gutenberg is in 18.5 (unreleased).

This is indeed that the Gutenberg class is being preferred, but core is expecting a newer version of the class, which doesn't yet exist in the plugin.

I can't duplicate the exact error, but I can get this:

Fatal error: Uncaught Error: Call to undefined method WP_Theme_JSON_Data_Gutenberg::get_theme_json() in wp-includes/class-wp-theme-json-resolver.php on line 257

Call stack:
WP_Theme_JSON_Resolver::get_theme_data() wp-includes/class-wp-theme-json-resolver.php:598
WP_Theme_JSON_Resolver::get_merged_data() wp-includes/global-styles-and-settings.php:182
wp_get_global_stylesheet() wp-includes/block-editor.php:511

#16 @joemcgill
5 days ago

This seems to be one of the unfortunate side-effects of the way we're currently handling the WP_Theme_JSON_ related classes between the Gutenberg plugin and WP/trunk. Even though the GB plugin prefers its own versions of those classes, we have several functions, like wp_get_global_stylesheet() that reference the core versions directly, by calling WP_Theme_JSON_Resolver::get_merged_data() rather than allowing for the opportunity for the WP_Theme_JSON_Resolver_Gutenberg class to be preferred.

We've talked about the possibility of consolidating all development of the WP_Theme_JSON_* classes to a package in the GB repo that would be synced to WP with other package syncs, but we would potentially still have this problem for anyone running trunk with a previous version of the GB plugin, or when the last sync before beta is made prior to the official 18.5 release date for GB (maybe an edge case?). The other option, would be to make sure that the GB related classes were extending the core versions even thought the way that approach was previously implemented was not a great DX (see the related ticket).

In the meantime, I think we need to add a check to make sure anything filtering the wp_theme_json_data_theme and related filters are returning a WP_Theme_JSON_Data object before calling the new method.

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


5 days ago
#17

  • Keywords has-patch added

This adds a method_exists check for backwards compatibility for any extenders who are returning a WP_Theme_JSON_Data compatible object from filters that have not yet implemented the new get_theme_json method in order to avoid errors like this one.

Trac ticket: https://core.trac.wordpress.org/ticket/61112

#18 @joemcgill
5 days ago

@ryelle and @dd32, I've opened a PR that should address the issue you've both reported. Could you give it a try and confirm that this fixes the issue?

Note: See TracTickets for help on using tickets.