[wp-trac] [WordPress Trac] #57916: Explore and assess 6.2 server-side performance regressions

[WordPress Trac]

#57916: Explore and assess 6.2 server-side performance regressions
----------------------------+--------------------------
 Reporter:  flixos90        |       Owner:  flixos90
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  6.2
Component:  General         |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  performance
----------------------------+--------------------------

Comment (by flixos90):

 I spent a bit more time researching this and got to one interesting and
 very positive finding:

 Since the `widgets_init` action was one of the primary offenders for the
 `init` regression, I first used
 [https://gist.github.com/felixarntz/63c05392dbf7d51cc7f8f4a424b1ff39 this
 Gist plugin] with a manually added call to include Server-Timings for
 every callback hooked to the `widgets_init` action.
 [https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit#gid=1500676996
 This sheet] shows the results from 100 runs. As you can see, the primary
 offender there is the `...-register-widgets` call, which refers to the
 `WP_Widget_Factory::_register_widgets()` function.

 Looking at the history, none of the widget foundation has been touched in
 the WP 6.2 cycle in any way that could even affect performance (see
 https://github.com/WordPress/wordpress-develop/commits/trunk/src/wp-
 includes/class-wp-widget-factory.php, https://github.com/WordPress
 /wordpress-develop/commits/trunk/src/wp-includes/class-wp-widget.php,
 https://github.com/WordPress/wordpress-develop/commits/trunk/src/wp-
 includes/widgets.php), so I was thinking that maybe it is something that a
 specific widget does when it is registered.

 So I hacked my WordPress installs to include Server-Timing metrics for
 every individual widget registration (couldn't do that from a plugin). I
 then did another Server-Timing benchmark doing 100 runs. I noticed that
 the `WP_Widget_Text` widget was generally way slower than the other
 widgets to register, and that had seemingly gotten worse in WP 6.2. I knew
 that @spacedmonkey had recently touched that widget in [55553] for
 performance reasons (only in `trunk`, so will only be included in WP 6.3),
 so I gave it a try to apply that change to my WordPress 6.2 installation.
 Then I ran the Server-Timing benchmark with 100 runs again.

 Turns out that fix brings a notable performance improvement that enhances
 the `widgets_init` performance so that the "regression" is gone.
 [https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit#gid=1901401012
 This sheet] shows it in detail: Compare column F with column D,
 particularly for rows 62-66. The faster performance in the registration of
 that widget is what brings down overall processing time for `widgets_init`
 by ~3ms, which happens because we avoid JSON-encoding some data there
 unnecessarily. Note that if you only fix this for the `WP_Widget_Text`
 class, the problem will instead surface in the `WP_Widget_Custom_HTML`
 class. It seems that for whatever reason, the JSON-encode call is
 expensive only the first time that it happens.

 Accordingly, the performance improvement for overall `init` is not ''as''
 high, but it's still 0.4ms - potentially because now some other code has
 the first JSON-encode call. But it's definitely a nice performance
 enhancement overall.

 I am still unsure how all that relates to why `init` performance of WP 6.2
 seems worse than in WP 6.1, since all that code had not been touched. It
 seems that indeed someone else affects it.

 Given that [55553] is simply a new performance enhancement and doesn't
 technically fix anything that was introduced in the 6.2 cycle, it doesn't
 justify being backported and can be included in 6.3. That said, I think
 it's a neat enhancement and technically improves the metrics we're seeing
 here.

 We may want to do some more research on why `widgets_init` is actually
 slower in 6.2 than 6.1, but at this point I'm unsure that will be
 fruitful. And at least we now have a good path forward to enhance this.

 I would still suggest to keep this ticket open to explore the other
 notable reason for the `init` regression, the `WP_Block_Supports::init()`
 function (see
 [https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit#gid=879358988&range=D95
 here].

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