[wp-trac] [WordPress Trac] #61782: Memoize wp_get_wp_version

[WordPress Trac]

#61782: Memoize wp_get_wp_version
------------------------------------+-----------------------------
 Reporter:  Cybr                    |       Owner:  SergeyBiryukov
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  6.7
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------------

Comment (by Cybr):

 I concur with Peter. You can skip to the last paragraph to get the
 conclusion.

 Still, a single parameter to force fetching the latest version could
 rewrite the cache (lest we not forget to use it):
 {{{#!php
 <?php
 function wp_get_wp_version( $reset = false ) {

         static $wp_version;

         if ( ! isset( $wp_version ) || false !== $reset )
                 require ABSPATH . WPINC . '/version.php';

         return $wp_version;
 }
 }}}

 I used `false !== $reset` here so we can write `wp_get_version( 'latest'
 )` or something, but that's a coding style preference. `true` is not
 conveying much as a parameter, but that's probably best left for another
 discussion.

 On WP 6.6.1 and WP 6.7-alpha-58846, on PHP 8.2 with OPcache, using Twenty
 Twenty-Two, no plugins, logged in, on the homepage, `version.php` is
 included 3 times:
 - 1x `wp_default_styles()`,
 - 1x `wp-settings.php`,
 - 1x `wp_scripts_get_suffix()`.

 In that context, with just plausible 3 calls to `wp_get_wp_version()`, the
 function, as per this comment, would save 0.04ms of load time compared to
 the non-memoizing function.

 At `/wp-admin/index.php` on 6.7-alpha-58846, `wp_get_wp_version()` is
 called 2 times:
 - 1x `_maybe_update_core()`,
 - 1x `core_update_footer()`.
 The `version.php` file is included 4 times:
 - 1x `wp-settings.php`,
 - 1x `wp_scripts_get_suffix()`,
 - 1x `wp_default_styles()`,
 - 1x `wp_get_wp_version()`.

 In that context, with just 5 plausible calls to `wp_get_wp_version()`, the
 function would save 0.06ms.

 The total load time of WordPress on the server I tested this with is about
 60ms.

 So, this can save anywhere from 0.06% to 0.1% of load time (one-1500th to
 one-thousandth of a relative impact).

 I'm pedantic and overly ambitious. Ignoring the law of diminishing returns
 and Zeno's paradox, just with 1000 times this kind of improvement, WP
 would load instantly.

 Realistically, however, 0.06ms of total savings isn't a lot.

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