[wp-trac] [WordPress Trac] #58317: Refactor determine_locale() for performance

[WordPress Trac]

#58317: Refactor determine_locale() for performance
----------------------------------------+--------------------------
 Reporter:  Cybr                        |       Owner:  swissspidy
     Type:  enhancement                 |      Status:  assigned
 Priority:  normal                      |   Milestone:  6.3
Component:  I18N                        |     Version:  trunk
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:  performance
----------------------------------------+--------------------------

Comment (by Cybr):

 I didn't test the total impact of function `determine_locale()` -- it
 would likely be negligible in the grand scheme. I created this ticket
 primarily to educate about various performance pitfalls.

 Doing these kinds of optimizations throughout WordPress's most called
 functions, such as `WP_Object_Cache::is_valid_key()`, would yield a
 significant improvement. Repeat this for all of WordPress Core, and I
 think we can at least halve the load times.

 I have some [https://github.com/theseoframework/wpcs-
 tsf/blob/v1.2.0/TSF/Sniffs/Performance/FunctionsSniff.php#L34-L45 slow PHP
 functions listed here]. For example, we should set `autoload: false` to
 all internal `class_exist()` calls, for it would prevent invoking
 autoloaders of plugins, especially since WP (still) doesn't use an
 autoloader --- and once WordPress has an autoloader, we could remove these
 calls altogether (see #36335, which derailed into handling dependencies
 via Composer because people still don't know about `spl_autoload()`).

 If you'd like, I could scan for WordPress's most called functions and
 create a ticket for each one with a greater than 0.1% PHP load impact,
 explaining what went wrong, how we can solve that, and how to prevent the
 issue in future updates. I'm afraid the biggest problem with WP now is
 that `wp-settings.php` loads over 200 files, many aren't even used at
 runtime on most sites (like 47 for REST, and another 10 for sitemaps).
 Autoloading should become of utmost priority, stat.

 https://core.trac.wordpress.org/ticket/50568 should also still need to be
 resolved for a 30% PHP performance boost; though, IIRC, in WP 6.2, the
 term cache handler changed.

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