Make WordPress Core

Opened 3 weeks ago

Last modified 4 days ago

#59314 new enhancement

Cache the result of template file lookups

Reported by: joemcgill's profile joemcgill Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Themes Keywords: needs-patch 2nd-opinion
Focuses: performance Cc:

Description

WP makes repeated file_exists operations for the same templates that rarely change. To reduce the overhead of these operations we should consider caching the result of get_query_template and use the cached path directly on subsequent requests.

Related tickets:
https://core.trac.wordpress.org/ticket/12491
https://core.trac.wordpress.org/ticket/40731

Design considerations

The design would need to account for the passed list of template candidates (the second parameter) by checking for a cached value after the {$type}_template_hierarchy hook is fired. If found, this would bypass the subsequent locate_template and locate_block_template calls in this function, otherwise would cache the value of the $template variable before it is passed to the final output filter.

To avoid fatal errors, the cached value should still be run through a file_exists check and fall back to the original locate_template function if false. Other cache invalidation strategies will need to be thought through as part of implementation to avoid these cached values becoming stale.

To keep the number of cache keys to a minimum, we could consider storing these as a single multi-dimensional array rather than distinct values.

Benefits

This would avoid the need to run file operations for the same template on multiple requests, given that these files rarely change unless the whole theme has been replaced. Even so, the performance impact of this change is still inconclusive, as file operations on many systems get natively cached by PHP so the impact may be smaller than anticipated based only on application profiling methods.

Caveats and risks

This benefit would be limited to sites running a persistent object cache since this value is only calculated once per request, unless this is implemented as a transient. While file operations do account for a noticeable percentage of the total time spent on the server during a request, this would only avoid the initial template file lookups, and not any additional template parts that are called during the rendering of a template file.

Since the template hierarchy allows a high level of granularity, even to the level of a specific post ID, this cache would need to account for potentially every URL, which could bloat caches. Additional performance evaluation should be conducted on any implementation before this is committed.

Note: A previous attempt at solving this problem was attempted in #40731 using a static cache instead of an object cache, but was determined to not be a significant enough benefit to warrant merging, so this would need to show clear performance benefits.

Change History (6)

#1 @spacedmonkey
3 weeks ago

We may also consider using glob to lookup on php / html files, caching that. Then the lookup would be if a path is in an array.

#2 @joemcgill
3 weeks ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Moving this to Future Release, since we're so close to the 6.4 beta release.

#3 @johnbillion
3 weeks ago

  • Keywords 2nd-opinion added

Calls to file_exists() should essentially be free due to the stat cache. I can't imagine we'll be able to increase performance by additionally caching the results in the object cache. Let's get some good before and after figures please.

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.


6 days ago

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


4 days ago

Note: See TracTickets for help on using tickets.