-
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 get_block_templates
performance
#4097
Improve get_block_templates
performance
#4097
Conversation
if ( $should_include ) { | ||
$query_result[] = $template; | ||
} | ||
$query_result[] = _build_block_template_result_from_file( $template_file, $template_type ); |
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.
This is the key change of this PR: instead of building the template object for all items and filter them after, we filter before this step, so we have to build less items. We can do this because all the data used to filter the items is already available in the step before.
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.
ok, this is now ready to review :) cc @youknowriad @ockham @creativecoder @carlomanf as people who has worked in this area, according to #1267 |
The perf job reports the following (copy/pasted here in a single table, otherwise it's difficult to compare the results):
|
Can't talk about the performance impact but this looks great to me. Thanks for the updates @oandregal |
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.
Thanks @oandregal for the update. I take another round of review and left some review and questions.
In my test i found:
- The changes only affect block themes, so they did not improve performance for the classic themes. That performance comparison for classic themes is due to GHA variance.
- For block theme(Fresh setup with a post):
- After the PR changes, the
_build_block_template_result_from_file
function called 7 times on the home page and 5 times on the post page, compared to 40 times on the home page and 22 times on the post page before the changes.
- After the PR changes, the
It's good improvement for the block theme.
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.
Thanks @oandregal for the changes. Can you share updated performance number?
Only return the theme templates that match the slugs we are looking for, instead of returning them all.
Only return template pats that match the area we are looking for, instead of returning them all.
Only return the theme templates that match the given postTypes, instead of returning them all.
Only return items that don't have a user-defined equivalent, instead of returning them all.
Co-authored-by: Jonny Harris <spacedmonkey@git.wordpress.org>
Co-authored-by: Mukesh Panchal <mukeshpanchal27@users.noreply.github.com>
Co-authored-by: Mukesh Panchal <mukeshpanchal27@users.noreply.github.com>
This reverts commit 6f62ae2.
Co-authored-by: Mukesh Panchal <mukeshpanchal27@users.noreply.github.com>
I've rebased this upon |
@oandregal How did you get the numbers from the perf CI job? I'm asking since they only really run for |
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 Outstanding work here! It's fair to say this is the most impressive single PR with major performance impact I have seen to date. 🥳
Based on a benchmark I just ran, this PR improves overall load time performance with block themes by an impressive ~15%.
Apologies for the delay in review, but it's safe to say this will be a major win for performance in WordPress 6.3 already - almost as good as all the improvements we got from WP 6.1 to 6.2 altogether.
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.
Thanks @oandregal, Awesome work.
🤔 Oh. I looked at the performance CI job that ran for this PR. My understanding was that the numbers under "Print performance test results" was this PR and the numbers under "Print base line test results" was the baseline to compare to. Is that how should I look at them @felixarntz ? The first time I ran my own numbers they were on the same range that the CI job, so I didn't bother doing my own again. Happy to if I'm reading this wrong.
Yeah, I don't understand this either. I presumed it was related to the variability of the tests. |
Ah that may be a misunderstanding and slightly confusing. The "base line test results" are not the current stats for Looking at the printed "performance test results" is a great idea though. What you need to compare that too though is the similar data for the last commit in All of that is of course not how this should work, but to be fair the performance CI workflow in its current stage was not yet meant to be used to assess PRs. Reporting diffs between the last commit in the branch and the PR automatically in a PR comment is high on the todo-list though :) |
This has been committed at https://core.trac.wordpress.org/changeset/55687 |
This has created an issue with child themes, see instructions at WordPress/gutenberg#53138 I'm looking into this. |
Fix at #4940 |
continue; | ||
} | ||
|
||
$is_not_custom = false === array_search( |
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.
This logic checks for both templates coming from the user ("custom" as it was defined here) and previously inserted templates (for example, it checks that a parent template is not added if the child already defined it). This wasn't properly ported and caused an issue.
Trac ticket https://core.trac.wordpress.org/ticket/57756
What
This PR improves the performance of block template resolution.
Why
It provides a performance improvement for block themes. This change should not affect themes that don't have block templates, given they bail early.
The effect of this PR according to the performance CI job:
How
The
get_block_templates
function is responsible to find block templates that match a given search. The function is provided a query parameter that is used to find the relevant user templates (database) and theme templates (file directory). The query parameter includes data such the slugs of the templates, the areas of the template parts, etc.I've found that the
get_block_templates
retrieves and processes all block templates provided by the theme, to filter out the ones that don't match after. This function can be more performant if it filters out the ones that don't match before processing them, so it only computes the data to be used.The following profile shows the impact of this modification:
_build_block_template_result_from_file
is called: 22 (before) vs 5 (after).How to test
.env
to production by applying the following patch:seq 100 | xargs -Iz curl -o /dev/null -H 'Cache-Control: no-cache' -s -w "%{time_starttransfer}\n" http://localhost:8889 | xclip -selection clipboard
.Notes
I submitted this PR to core instead of Gutenberg because it modifies functions that are no longer there:
_get_block_templates_files
: no longer present.get_block_templates
: the correspondinggutenberg_get_block_templates
is still present, but it'll be removed once WordPress 6.2 is published. It won't be present in Gutenberg when this PR lands (WordPress 6.3 cycle).