[DanielDarrenJones]

A page often outputs the same nav more than once: a desktop menu and a mobile one is the usual case. Each {{ nav }} tag builds the tree, augments every page in it and works out every URL from scratch, even when an identical tree was built a moment ago for the tag above it.

The tree a tag builds is now kept for the rest of the request and reused by later tags for the same nav.

What counts as the same tree

Parameters that change which pages are in the tree (show_unpublished, include_home, from, site, conditions) identify it. Parameters that only change how much of it is shown don't: max_depth, limit, offset, select, include_parents, as and scope.

• A tree built with no max_depth serves any depth.
• A tree built to a depth serves the same or a shallower one.
• A tree built to a depth that turned out to reach the bottom serves any depth. Page::hasChildren() is new, and is how the tag knows whether it was cut short.
• A tag with a parameter that isn't a plain value builds its own tree, as before.

is_current and is_parent are still worked out for each tag, so the current URL isn't part of what's kept.

What is kept

• The built tree, in its own Blink store.
• For each page object in it, what that page contributes wherever it's shown: its augmented values, its URL, its absolute URL and whether it's external. This is in a WeakMap held in Blink, so it's keyed by the object itself and goes when the page does.

Both last for the request, like anything else in Blink.

A tree saved partway through a request

The tree's own contents are part of the key, so a nav or collection tree that's saved after a tag has output it is built again. it_sets_is_current_and_is_parent_for_a_nav saves a second tree halfway through and fails without this.

An entry in the nav that's changed after the nav was output (its title, URL or status) is not picked up by a later tag in the same request.

Queue workers and Octane

Octane gets a fresh Blink for each request, so nothing is carried from one request to the next.

A queue worker has no requests, and Blink isn't cleared between its jobs. What the tag has kept is dropped when a worker moves on to its next job, so a job that outputs a nav doesn't see the one an earlier job built. This follows the same rule as the Stache's own reset between jobs: only in a queue: or horizon: process, so a job run synchronously during a request leaves that request's trees alone.

Benchmark

Each page requested with and without this change, one PHP process per request with a warm Stache, run alternately for 3 rounds of 6 (Apple M1 Pro, PHP 8.5, 6.x at 5b60554). The site is a generated one: 358 entries, 65 Antlers templates, and a three-level main nav of 155 items output twice in the header, once with max_depth="3" and once with no parameters, plus a footer nav. The bench is at https://github.com/1994limited/statamic-bench.

Page	Before	After
Simple page	191.8 ms	170.7 ms	−11.0%
Nested page	200.6 ms	180.5 ms	−10.0%
Page builder page	365.4 ms	342.8 ms	−6.2%
Article	271.0 ms	247.8 ms	−8.6%
Article listing	306.4 ms	292.8 ms	−4.4%
Tag listing	285.6 ms	262.8 ms	−8.0%
Product	225.7 ms	209.6 ms	−7.1%
Product listing	270.9 ms	246.6 ms	−9.0%
Event	210.4 ms	186.9 ms	−11.1%
Team listing	206.3 ms	183.6 ms	−11.0%
404	189.4 ms	164.9 ms	−12.9%
Home	333.4 ms	318.3 ms	−4.5% (within noise)
A page with no nav	181.2 ms	180.5 ms	no change

The saving is roughly 15 to 25 ms a page, which is the second build of the main nav. A site that outputs each nav once gains nothing, and loses nothing measurable. Peak memory moved by less than 3 MB either way.

The HTML of every page is byte for byte the same before and after.