[wp-trac] [WordPress Trac] #56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a public function
WordPress Trac
noreply at wordpress.org
Tue Jan 24 20:46:59 UTC 2023
#56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a
public function
-------------------------------------------------+-------------------------
Reporter: oandregal | Owner:
| hellofromTonya
Type: enhancement | Status: reopened
Priority: normal | Milestone: 6.2
Component: Themes | Version:
Severity: normal | Resolution:
Keywords: gutenberg-merge has-patch has-unit- | Focuses:
tests has-testing-info | performance
-------------------------------------------------+-------------------------
Comment (by dmsnell):
Thanks @flixos90 - I'm definitely not suggesting we ignore performance
problems. My comment was supposed to say something more like "can we
establish that the metrics we've collected amount to the scale of the
problem we think they do?"
To that end I suspect measuring real page renders with req/s might be more
illustrative of the real performance impact, and also that we consider the
hit-rate of the cache when thinking about standard recommended setups,
including HTTP-server page caches that eliminate all of the code in
question for the overwhelming majority of page renders.
Again, the 48ms value seems wildly unexpected, and if a call to
`file_exists()` can amount to that much time then something seems very
wrong somewhere. A value of 4ms seems less surprising, though.
Did anyone already mention or discuss how
[https://www.php.net/manual/en/function.is-readable.php#refsect1-function
.is-readable-notes is_readable()] is already cached by PHP? I thought the
discussion centered around the filesystem access, but maybe it's more
about `get_template_directory()`?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56975#comment:98>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list