do_blocks(): Free up transient memory leak #8999
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dmsnell
added a commit
to dmsnell/wordpress-develop
that referenced
this pull request
Jun 18, 2025
There has been a memory inefficiency inside of `do_blocks()` where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call to `do_blocks()`. In this change, each parsed block sub-tree is freed via reset to `null` after it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them. For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same `memory_limit`. Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post.
dmsnell
force-pushed
the
blocks/free-processed-blocks-after-doing-them
branch
from
fdefc5e to
5261e3d
Compare
There has been a memory inefficiency inside of `do_blocks()` where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call to `do_blocks()`. In this change, each parsed block sub-tree is freed via reset to `null` after it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them. For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same `memory_limit`. Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post. Fixes #63588
dmsnell
force-pushed
the
blocks/free-processed-blocks-after-doing-them
branch
from
5261e3d to
e4d4f1c
Compare
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. |
joemcgill
approved these changes
Jun 18, 2025
pento
pushed a commit
that referenced
this pull request
Jun 18, 2025
There has been a memory inefficiency inside of `do_blocks()` where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call to `do_blocks()`. In this change, each parsed block sub-tree is freed via reset to `null` after it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them. For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same `memory_limit`. Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post. Developed in #8999 Discussed in https://core.trac.wordpress.org/ticket/63588 Props dmsnell, joemcgill. Fixes #63588. git-svn-id: https://develop.svn.wordpress.org/trunk@60316 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith
pushed a commit
to markjaquith/WordPress
that referenced
this pull request
Jun 18, 2025
There has been a memory inefficiency inside of `do_blocks()` where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call to `do_blocks()`. In this change, each parsed block sub-tree is freed via reset to `null` after it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them. For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same `memory_limit`. Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post. Developed in WordPress/wordpress-develop#8999 Discussed in https://core.trac.wordpress.org/ticket/63588 Props dmsnell, joemcgill. Fixes #63588. Built from https://develop.svn.wordpress.org/trunk@60316 git-svn-id: http://core.svn.wordpress.org/trunk@59652 1a063a9b-81f0-0310-95a4-ce76da25c4cd
github-actions bot
pushed a commit
to platformsh/wordpress-performance
that referenced
this pull request
Jun 18, 2025
There has been a memory inefficiency inside of `do_blocks()` where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call to `do_blocks()`. In this change, each parsed block sub-tree is freed via reset to `null` after it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them. For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same `memory_limit`. Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post. Developed in WordPress/wordpress-develop#8999 Discussed in https://core.trac.wordpress.org/ticket/63588 Props dmsnell, joemcgill. Fixes #63588. Built from https://develop.svn.wordpress.org/trunk@60316 git-svn-id: https://core.svn.wordpress.org/trunk@59652 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Trac ticket: Core-63588
There has been a memory inefficiency inside of
do_blocks()where it parses the given content then iterates through each top-level block to render it. Unfortunately each top-level block can considerably add to the overall memory use involved, and once moving on to the next top-level block, all of the allocated memory will be retained until the end of the call todo_blocks().In this change, each parsed block sub-tree is freed via reset to
nullafter it has been rendered. All top-level blocks are rendered independently of each other and so this operation is safe — there are no data dependencies between them.For a test post of length 2.3 MB containing 138 top-level blocks, this brought the minimum memory requirement for the PHP process down from around 450 MB to around 316 MB. This was “around” since the memory requirements are non-deterministic and some runs will succeed while other runs will crash for out-of-memory given the same
memory_limit.Impact of this change will be most profound when there exist one or more top-level blocks which allocate a significant amount of memory which are not the last top-level-block in a post. This means that this change might even impact small and typical posts, if the right blocks are near the start of the post.