Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation: minimize the number of innerblocks renders #58506

Closed
wants to merge 1 commit into from

Conversation

oandregal
Copy link
Member

@oandregal oandregal commented Jan 31, 2024

NOT TO MERGE.

What?

This PR is an experiment to minimize the number of $inner_blocks renders in the navigation block.

Why?

The initial package update for 6.5 took a performance hit. Part of it was due to the navigation block render refactor at #55605. That PR increased from 1 to 6 the number of times its inner blocks rendered, causing a cascade of other updates, degrading performance.

Before Update After update This PR
Total time (ms) 2 117 2 517 2 227
render_block_core_navigation (ms) 106 334 160
# calls to WP_Block->render 410 415 411

See also some kcachegrind visualizations:

Before After This PR
Captura de ecrã 2024-01-31, às 16 20 46 Captura de ecrã 2024-01-31, às 16 21 23 Captura de ecrã 2024-01-31, às 16 21 48

I'm also sharing the cachegrind-logs.zip for people to inspect by their own. qcachegrind (macos) or kcachegrind (linux) can be used to open and inspect the files (see images in table).

How?

TBD.

The test case here just demonstrate how this is an issue, but it's not the proper implementation.

Testing Instructions

TBD.

The performance tests in Gutenberg won't report any performance impact, the same #55605 didn't. The reason is that the test data doesn't cover the navigation block appropriately. The core performance tests cover more ground for the navigation block.

These changes are ported to core via the @wordpress/block-library package. How can we test the changes in this PR in core?

Copy link

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core.
  • Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

foreach ( $inner_blocks as $inner_block ) {
$inner_block_content = $inner_block->render();
$p = new WP_HTML_Tag_Processor( $inner_block_content );
$inner_blocks_content = static::get_inner_blocks_content( $inner_blocks );
Copy link
Member Author

@oandregal oandregal Jan 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What we need to do is making suer inner blocks only render once for the navigation block. These are not the changes we need, but it helps demonstrate the impact.

Options:

  1. Refactor the code for the inner blocks to be rendered once at WP_Navigation_Block_Renderer::render.
  2. Cache the inner blocks rendering.

I'd very much prefer 1, given this code is new, and so we can make any modifications to it. Once it's in core we won't. Caching moves the issue from time to memory.

@oandregal
Copy link
Member Author

Closing in favor of #58513

@oandregal oandregal closed this Feb 1, 2024
@oandregal oandregal deleted the fix/navigation-inner-blocks-render branch February 1, 2024 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant