[wp-trac] [WordPress Trac] #45471: Allow caching of parse_blocks results

[WordPress Trac]

#45471: Allow caching of parse_blocks results
--------------------------+-----------------------------
 Reporter:  joostdevalk   |       Owner:  francina
     Type:  enhancement   |      Status:  assigned
 Priority:  normal        |   Milestone:  Future Release
Component:  Cache API     |     Version:  5.0
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:  performance
--------------------------+-----------------------------

Comment (by dmsnell):

 It’s yet-again been a while but the caching debate is always lively. In
 the meantime I’ve collected significantly more data in practice. I will
 say that it points to even more risk in caching the parsed blocks. Parsing
 is relatively fast, but numerous posts, particularly malformed posts, can
 lead to memory explosions.

 Perhaps I’ve mentioned it in other tickets, but I saw a 3 MB post require
 14 GB of memory to parse. If we add caching we are likely to only make the
 existing problem worse, leading to more DoS activity in post parsing. The
 root problem is the recursive structure of blocks which contain recursive
 copies of strings.

 We’ve been working with a modified version of my block scanner from
 [#6760](https://github.com/WordPress/wordpress-develop/pull/6760) / #61401
 at Automattic and it’s serving well. Currently I’m reworking some code
 further to account for missed performance opportunities. Unlike caching,
 it addresses the problem of efficiency in similar ways to how the HTML API
 does it — by doing less work.

 In the coming two weeks I hope to have that PR/Ticket updated with code
 we’ve tested. While not directly addressing `parse_blocks()`, it adds a
 new means to scan through the blocks in a post which is both faster than
 `parse_blocks()` and also offers essentially zero-memory-overhead parsing
 at that. Another benefit of this new approach is that it’s possible to
 //stop// parsing after a given point, for example, when generating an
 excerpt. Doing that is another area where we can leap ahead of cached
 parse results and avoid all of the various risks that caching introduces.

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