-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve performance in the WP_Theme_JSON class by simplifying calls to array functions #3555
Conversation
3ddcf7e
to
d0bc5f2
Compare
These 2 functions only differ if the value in one of the items of the array has a value of null - something that can't ever happen in this scenario. isset() is significantly faster so changing it makes sense in this context.
Checked each of these cases to ensure that value is never null
52ae187
to
213e94b
Compare
While doing some profiling, I noticed there are still calls to |
@@ -2317,6 +2343,9 @@ public function merge( $incoming ) { | |||
) { | |||
_wp_array_set( $this->theme_json, $path, $content ); | |||
} else { | |||
$slugs_node = static::get_default_slugs( $this->theme_json, $node['path'] ); | |||
$slugs = array_merge_recursive( $slugs_global, $slugs_node ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wasn't added, it was just moved here. 😉
A few lines above we were calling these 2 on the previous foreach
loop (used to be line 2281), so they were always running. Instead of always calling them, we moved them here where they are actually used. This way these rather expensive calls run fewer times, only when necessary.
I wouldn't worry too much about (or overestimate) the impact of
Note: |
Yeah, that's an important distinction! |
@jrfnl @aristath Following up on
For example, instead of: if ( array_key_exists( $element, static::__EXPERIMENTAL_ELEMENT_CLASS_NAMES ) ) {
} Do: $element_class_names = static::__EXPERIMENTAL_ELEMENT_CLASS_NAMES;
if ( isset( $element_class_names[ $element ] ) {
} Again, not saying this is necessarily worth doing (and certainly not a blocker), but I'd be curious if the first or the last is generally faster. :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes here look solid to me!
I of course trust the benchmarking data provided in https://core.trac.wordpress.org/ticket/56974#comment:1, but it may additionally be helpful to quantify the performance gain here in milliseconds as well.
Given that parsing theme.json
affects the wp_head
action quite a bit (see also #3536), I thought I'd do a performance comparison there first. Based on 9 test runs, the median impact there is small but consistent:
- With Twenty Twenty-Three (i.e. block theme): 26.63ms vs 27.78ms (~4% faster)
- With Twenty Twenty-One (i.e. classic theme): 15.30ms vs 16.05ms (~5% faster)
See this spreadsheet for the full data.
So also in that regard it looks like a small but worthwhile win. Potentially I can do the same for more concretely the parsing of theme.json
itself as that would be even closer to the changes here and allow us to quantify impact in that way too.
There's bound to be more room for improvement, but yes, let's take this step by step and I do believe this is a valuable step in that. Re: assign+ On that note - PHP 8.3 will bring another very useful improvement |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a few nits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall. Commented with a few small questions/suggestions, but none of them are really to be considered blockers.
Committed in https://core.trac.wordpress.org/changeset/54804. |
@@ -2035,7 +2056,9 @@ public function get_styles_for_block( $block_metadata ) { | |||
// the feature selector. This may occur when multiple block | |||
// support features use the same custom selector. | |||
if ( isset( $feature_declarations[ $feature_selector ] ) ) { | |||
$feature_declarations[ $feature_selector ] = array_merge( $feature_declarations[ $feature_selector ], $new_feature_declarations ); | |||
foreach ( $new_feature_declarations as $new_feature_declaration ) { | |||
$feature_declarations[ $feature_selector ][] = $feature_declaration; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aristath @desrosj @felixarntz @spacedmonkey @jrfnl @hellofromtonya
Shouldn't the variable assigned be $new_feature_declaration
instead of $feature_declaration
? This has been reported as problematic by the Gutenberg lint jobs (see conversation).
I haven't looked at what regression this introduced but it'd be good to create a follow-up PR fixing it and adding a test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oandregal I concur. This is a bug which should be fixed.
$feature_declarations[ $feature_selector ][] = $feature_declaration; | |
$feature_declarations[ $feature_selector ][] = $new_feature_declaration; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦 yeah, looks like this was a typo.. Good catch 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happens to the best of us ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with this code path, so asked folks to provide details for testing at WordPress/gutenberg#46579 (comment) so we can add a new unit test and gauge how severe this is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICS, this should go in the next 6.1 patch release.
Edit to clarify: I'm basing this assessment on the following:
- It's very clearly a bug with an obvious fix.
- It's likely a regression compared to previous behaviour.
Trac ticket: https://core.trac.wordpress.org/ticket/56974
This PR simplifies expensive array-functions calls where appropriate.
Attaching some profiling results to showcase the impact.
Before (trunk):
After (with this PR):
All numbers in the screenshots above use milliseconds, and the impact of these seemingly simple changes is bigger than expected, shaving off more than 200ms. Of course those numbers are a bit inflated due to the fact that profiling slows down a page significantly, but the overall improvement on the page-load is more than 3%.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.
props @jrfnl 🙌