Editor: Speed up core block style file lookups - #12798
Conversation
`register_core_block_style_handles()` checked each candidate stylesheet against the core block CSS file list with `in_array()`. The closure runs three times per core block, so every request walked that list hundreds of times looking for an exact string match. Index the file list once with `array_fill_keys()` and use `isset()` for the lookups instead. Both keys are always non-numeric strings, so the key lookup matches the strict `in_array()` comparison it replaces. Also defer `wp_normalize_path()` until after the early return, since the normalized path is only used when the stylesheet exists. See #65779.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
irozum
left a comment
irozum
left a comment
There was a problem hiding this comment.
This is a sound, low-risk optimization that does exactly what the ticket proposed (and the ticket author's own benchmark backs the 44% reduction claim). I checked the in_array() → isset() swap for the edge case that usually bites this kind of change — PHP's numeric-string array key coercion — but every $style_path/$rtl_file value is built as "{name}/{filename}{suffix}.css", so it always contains a slash and a .css suffix and can never collide as an integer key; isset() on array_fill_keys( $files, true ) is exactly equivalent to in_array( ..., true ) here. The wp_normalize_path() reorder is also correct: $path is only read after the early return (in the add_data( 'path', ... ) call and the RTL str_replace), so deferring it changes nothing observable.
Ran Tests_Blocks_RegisterCoreBlockStyleHandles (452 tests, all green) plus PHPCS lint:errors and PHPStan, both clean. The existing data provider does cover all three changed branches — the early-return (no stylesheet) case, the normal registration path, and the RTL variant — so the "no new tests needed" claim in the PR holds up.
|
Thanks for the PR! Closing in favour of #12802. |
3 participants
register_core_block_style_handles()checked each candidate stylesheet against the core block CSS file list within_array(). The closure runs three times per core block, so a request walked that 624-entry list roughly 270 times.What the problem was:
in_array()scans per closure call, each walking the full file list.wp_normalize_path()ran before the early return, so the result was computed and discarded for every stylesheet that does not exist.What the fix does:
array_fill_keys()and usesisset()for both lookups.wp_normalize_path()until after the early return.Approach and why:
.css, so key lookup is equivalent to the strictin_array()it replaces. Verified against the real file list: 624 files, 0 keys coerced to integers, 0 lookup mismatches againstin_array( ..., true ), including numeric and empty probes.Trac ticket: https://core.trac.wordpress.org/ticket/65779
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Ticket analysis and tests. All changes were reviewed and validated by me.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.