Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #57916, comment 16


Ignore:
Timestamp:
03/23/2023 06:10:56 PM (16 months ago)
Author:
flixos90
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #57916, comment 16

    initial v1  
    33I 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.
    44
    5 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.
     5That 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 `isset( $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.
    66
    77Any 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!