[wp-trac] [WordPress Trac] #56975: Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a public function

[WordPress Trac]

#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 flixos90):

 @dmsnell I measured performance of the latest static cache approach in
 https://docs.google.com/spreadsheets/d/1lTw0d4iyNJ91Jg0Ru3RXCMvSASRaV5vFIsWIkgOjBTU/edit:
 The relative performance win for the function's overall execution time is
 significant (0.04ms compared to 4.34ms). Overall these values are small,
 but it is critical that we keep optimize performance of WordPress across
 the board, and those improvements add up over time. The data we have
 gathered clearly shows this is worthwhile.

 > Has anyone complained about this code slowing down their sites?

 I don't think this is how we should approach performance optimization. The
 average WordPress end user has no idea why their site is slow; they
 wouldn't be able to identify a concrete function in WordPress core to be
 slow, so we cannot rely on someone complaining.

 > Ship without a cache so we can better gather data.

 Gather data how? We don't have a way to gather data on how a concrete
 function performs on production sites, so we need to do our due diligence
 on assessing performance as we are developing it.

 > The fact that we're all recognizing a wide array of places where
 improper cache invalidation could triggers visible breakage in sites
 speaks to me that there's a high risk in caching this function the way
 we're talking about. I think this current discussion started when this
 same subsystem blocked all `wp-admin` CSS

 There has not been outlined any concrete breakage that occurred during
 testing of this performance enhancement. This is a non-persistent cache,
 so it would only need to be invalidated if the current theme switched
 within the same request and if the function would be called before ''and''
 after the theme switch.

 The `wp-admin` breakage was a critical problem, but that was unrelated to
 the performance implications of cache usage, and we have already found a
 way to solve this problem.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56975#comment:97>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform