[DanielDarrenJones]

Blueprint and fieldset files are parsed from YAML on every request that uses them; Blink only keeps them for that request. Page builder blueprints are often tens of kilobytes. Symfony YAML takes about 18 ms to parse an 85 KB one, and reading the parsed array back from a cache takes about 0.05 ms.

Blueprint and fieldset files are now parsed through a small internal ParsedYamlFiles class:

• It keeps the parsed array in the Stache's cache store, together with an xxh128 hash of the file's contents.
• A file whose contents no longer match the stored hash is parsed again. Edits are picked up on the next request, including ones that keep the same size and modification time, and nothing needs clearing.
• The key is the path within the app, so deploys into a new release directory reuse the entries.
• Parse errors still point at the file, and nothing is stored for a file that fails to parse.

Benchmark

A generated site on 6.40.0 with an 85 KB page builder blueprint. Each request runs in its own PHP process, as PHP-FPM serves it (boot not timed, opcache on), median of 5, on an M1 Pro with PHP 8.5.

Control panel:

Page	Before	After
Collections index	95.8 ms	78.1 ms
Collection page	79.5 ms	59.7 ms
Blueprints index	74.4 ms	56.4 ms
Blueprint edit	75.7 ms	58.6 ms
Entry edit	163.2 ms	132.3 ms
Entry create	105.4 ms	86.2 ms

Peak memory on those pages drops by about 2 MB.

On the front end of the same site, page builder pages are 10–12% faster and other pages are within noise. The rendered HTML is unchanged, including after content edits.

I also checked in the CP that changing a blueprint, either in the file or through the blueprint editor, shows up on the next page load.

Tests

ParsedYamlFilesTest:

• parses a file;
• reuses the stored result while the file is unchanged;
• parses again when the contents change, even with the same size and modification time;
• stores nothing for a file that fails to parse, and the error names the file;
• an empty file gives [].

The full suite passes.