Hey Jonny, have you seen WordPress/gutenberg#45171?

I'm interested in moving some of those tasks forward, and I'm optimistic they'll have a big impact in terms of performance and code quality. See for example this prototype that reduces the total time of a request from 514.44ms to 343.71ms, a 33% performance increase. I like to take a more data-driven approach to changes than we did in the past. Measure how performance is actually affected with changes. During the 6.1 cycle, there were many changes that required attention during RC, which is far from ideal.

Also, some of the changes in this PR become unnecessary when we land the new public API methods proposed WordPress/gutenberg#45171 For example: WP_Theme_JSON_Resolver::theme_has_support() would be wp_theme_has_theme_json (already landed in Gutenberg), and WP_Theme_JSON_Resolver::get_theme_data()->get_patterns() would be wp_get_remote_patterns_from_theme.

Additionally, it'd be good to land these sort changes in Gutenberg first, so they can be tested widely in the plugin so bugs are caught earlier.

oandregal. I am seeing similar numbers in my testing, 0.4940s trunk compared 0.3423s to the same here.

The difference with this PR, as it uses classes properties, it is far more testable and readable. I strongly believe that the path forward is to convert this code to use an object.

It also means in the gutenberg plugin, that the global can be overridded, for better prototyping.

Backwards compat is going to be an issue here, as even through this class is private, it is being used by plugins already.