[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:  closed
 Priority:  normal          |   Milestone:  6.2
Component:  General         |     Version:  trunk
 Severity:  normal          |  Resolution:  fixed
 Keywords:  has-patch       |     Focuses:  performance
----------------------------+--------------------------
Changes (by flixos90):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 Thanks @spacedmonkey, that makes sense.

 I just gave it another look and did some quick benchmarks, looks like the
 new logic for the `position` support isn't in any way slower than that of
 other block supports features, so there's probably nothing we would need
 to do specific to the new feature.

 That said, I noticed some potential areas of improvement in the
 `WP_Block_Supports` class logic in general, for example the
 `register_attributes()` method calls every block supports feature's
 registration function for every block that exists, which means a
 potentially small change there could make a meaningful difference due to
 the many calls. One thing that looks unnecessarily complex and potentially
 slow to me is that that method already has access to the
 `$block_type->supports` property where it could just check if the specific
 feature is supported by the block type before (unconditionally) calling
 the registration function. The individual registration functions then all
 use `block_has_support()` with `_wp_array_get()`, which seems a bit
 backwards since it's always just one element: For example, checking
 `$block_type->supports['position']` is lighter than `_wp_array_get(
 $block_type->supports, array( 'position' ) )`. Not sure if this will make
 a difference in performance, but due to the common usage may be worth
 exploring.

 Any follow-up investigation for related performance enhancements would be
 decoupled from potential 6.2 regressions, so I think it's fair to say we
 have figured out what's going on here and no further action is required.
 Thanks everyone for helping out here!

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