[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 21:11:47 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 hellofromTonya):
Replying to [comment:98 dmsnell]:
> 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()`?
It don't think it's about `is_readable()`. It's about the calls to
`get_stylesheet_directory()` and `get_template_directory()` and each of
their call stacks.
I think in this case, the memoization (static cache variable) approach
implemented in [https://github.com/WordPress/wordpress-develop/pull/3887
PR 3887] is a win. Why?
* lean
* non-persistent
* low risk
* encapsulated
* micro-optimization gains
* no BC concerns
* easily changeable
* not uncommon in Core
What do you think @dmsnell? Any concerns for committing it?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56975#comment:99>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list