Skip to content
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

Cache wp_theme_has_theme_json via static variable #3887

Closed
wants to merge 5 commits into from
Closed

Cache wp_theme_has_theme_json via static variable #3887

wants to merge 5 commits into from

Conversation

oandregal
Copy link
Member

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

This PR implements caching to wp_theme_has_theme_json using a static variable.

@hellofromtonya
Copy link
Contributor

Per discussions in the Trac ticket, f8d09bc removes the cache reset and $can_use_cache logic in wp_theme_has_theme_json(). The removal of the function param is also for BC considerations should this param not be needed.

However, a reset of some sort is still needed between automated tests. Else, tests will fail (as seen by the commit ❌ ).

Comment on lines 269 to 278
/*
* Ignore cache when `WP_DEBUG` is enabled. Why?
* - to avoid interfering with the theme developer's workflow.
* - to reset between each automated test.
*
* @todo Replace `WP_DEBUG` once an "in development mode" check is available in Core.
*/
if ( WP_DEBUG ) {
$theme_has_support = null;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As noted in #3887 (comment), a static cache reset is needed to reset after each automated test. This can be accomplished in many ways:

  • Checking constants like WP_DEBUG and/or WP_RUN_CORE_TESTS
  • Adding a hard reset parameter to the function
  • Filtering
  • Global

There is precedence within Core for using the WP_DEBUG and `WP_RUN_CORE_TESTS constants.

I'd suggest avoiding the approach of adding a reset param to the function. Why? (a) BC concerns for the future if the param is no longer needed and (b) performance concerns of exposing a hard reset in prod.

However if a hard reset option is needed, for example on theme switch or preview, then the param can be added and constant(s) removed.

cc @felixarntz @azaozz @oandregal What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could also combine the check with early bail-out below.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hellofromtonya +1 to avoid the function parameter, I'd be concerned about BC with that too.

IMO the WP_DEBUG approach is the most suitable for now, since that's what we were going to go with at this point anyway (keeping in consideration the @todo comment to iterate on it with a more appropriate solution). Later, once there is e.g. a filter for this too, we would be able to adjust the tests themselves to decide on whether or not the static variable cache should be used here or not. That's why I think WP_DEBUG works best for this for now.

Nit-pick, can you move it from the extra if clause to the existing one below? IMO no need to have a clause to reset the static cache value when we could instead not use the static cache at all. Having WP_DEBUG in the existing clause below is also better in line with how we would like to adjust this code in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, I think none of that is really great, but I think keeping the static and relying on WP_DEBUG has the least impact on anything global that we wouldn't be able to change later, and it's relatively close to where we want this code to go eventually.

Comment on lines 276 to 280
if ( WP_DEBUG ) {
$theme_has_support = null;
}

if ( null !== $theme_has_support ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment in https://github.com/WordPress/wordpress-develop/pull/3887/files#r1084500610:

Suggested change
if ( WP_DEBUG ) {
$theme_has_support = null;
}
if ( null !== $theme_has_support ) {
if ( ! WP_DEBUG && null !== $theme_has_support ) {

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking more about the constants, I agree with @azaozz to also use WP_RUN_CORE_TESTS specifically for the tests. In this way, it provides clarity on the purpose of both constants, especially for the future when a "development mode" is introduced into Core.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d0ee044:

@azaozz and @felixarntz can you re-review please? Thanks!

@azaozz
Copy link
Contributor

azaozz commented Jan 24, 2023

+1 to using WP_RUN_CORE_TESTS to invalidate/reset the cache when running tests. That's the primary use for this constant, right?

Regarding use of WP_DEBUG to invalidate the cache while developing. Like @felixarntz thinking this is okay for now and should be replaced once core has a (well established) way of setting development mode. There's a trac ticket for that: https://core.trac.wordpress.org/ticket/57487.

The only case that seems a bit unclear when using a static is whether invalidating the cache may be needed while PHP is running. Reading through the newer comments on https://core.trac.wordpress.org/ticket/56975, seems it will not be?

@spacedmonkey spacedmonkey self-requested a review January 24, 2023 12:48
@spacedmonkey
Copy link
Member

2021 theme.

Before

Screenshot 2023-01-24 at 14 31 13

After

Screenshot 2023-01-24 at 14 31 23

This saves 40+ calls to is_readable which saves 48ms per page request. This is worth doing.

@hellofromtonya
Copy link
Contributor

Awesome! Thanks @spacedmonkey for running this before and after analysis #3887 (comment) 👏

Copy link
Contributor

@hellofromtonya hellofromtonya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This patch LTGM as it implements the lean performance approach discussed in the Trac ticket. There seems to be good consensus for it 👍

Copy link
Member

@felixarntz felixarntz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @oandregal!

Copy link
Contributor

@azaozz azaozz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using WP_DEBUG (until better indication for "development mode" exists in core), and ! WP_RUN_CORE_TESTS looks good imho.

@hellofromtonya
Copy link
Contributor

Thank you everyone for your contributions to land on this solution. Committed via changeset https://core.trac.wordpress.org/changeset/55138.

@ribaricplusplus
Copy link
Member

ribaricplusplus commented Mar 25, 2023

2021 theme.

Before

Screenshot 2023-01-24 at 14 31 13

After

Screenshot 2023-01-24 at 14 31 23

This saves 40+ calls to is_readable which saves 48ms per page request. This is worth doing.

@spacedmonkey Sorry for not directly relevant question, but could you let me know which tool you used for this profiling?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants