[DanielDarrenJones]

stache:clear (and so stache:refresh) forgets which indexes queries have used. The warm that follows then only builds the configured indexes, and the first requests afterwards build the rest themselves, each by loading every item in the store.

This keeps the list when a store is cleared, so the next warm builds the indexes the site actually queries.

On a generated site of 11,771 entries (6.42.0, stache:clear then stache:warm, then the first request to each page):

First request to	Before	After
/	2.31 s, 788 MB	1.00 s, 188 MB
/articles	2.27 s, 789 MB	0.89 s, 190 MB

The warm itself took the same time and memory either way (21.4 s, 1.3 GB), as it was already building these indexes before the list had been forgotten once.

With a 256 MB memory limit those first requests fail rather than being slow.

Two things this doesn't do:

• A whole cache flush (cache:clear) still loses the list.
• An index that was used once and no longer is stays in the list, so it keeps being built by the warm. That was already the case between clears.

Why it was being cleared

It doesn't look like it was to fix anything. The list has been forgotten since clear() was first written (7241012, "Driver agnostic stache clear"), along with everything else the store had cached.

The line next to it, which resets the list on the store itself, came later in #3485 to fix #3476. Clearing had forgotten the cached list but left the one on the store, so the store thought the path index was already recorded and never wrote it back. That showed up in asset containers, which are cleared on every request when the watcher is on.

Keeping both doesn't bring that back, as the two can no longer disagree.

Found by @godismyjudge95, who measured this on a much larger site and shared the fix.