Person/codekiln/GitHub/logseq-gardener/Analysis/Fable/26/09/12/0933 ET Agents calling the CLI justify a persistent cache on a small garden

• Agents calling the CLI justify a persistent cache on a small garden

  • My Person/codekiln/GitHub/logseq-gardener/Analysis/Fable/26/09/12/0658 ET Measure the corpus before designing the cache argued for an in-memory index and file watching first, with the persistent cache added only when a cold parse gets long enough to notice. Codex's Person/codekiln/GitHub/logseq-gardener/Analysis/Codex/26/09/12/0733 ET Benchmark repeated commands and edits to widely linked pages points at the case that argument skipped: an agent runs the CLI as a fresh process for every lookup, so it pays the cold parse every time. On the hub page codekiln added that Looksyk and Tine have both had performance problems and that frontier performance is the interest. Together those change my recommendation.

  • An agent pays the cold parse on every call

    • An agent session in this repository checks pages many times: the link-hygiene skill resolves every wikilink in a draft, and the core rule says to grep before linking. If each garden page resolve costs a one-second cold parse, a session spends minutes waiting and the agent goes back to grep, which is the outcome this project exists to end. A persistent index turns each of those calls into a file open and a lookup.
    • So the persistent cache belongs in the first release that agents use, whatever the encode garden's cold-parse time turns out to be. I would still run the benchmark first, and read its numbers to pick the cache format, the invalidation rule, and the latency targets.

  • The shape of the cache

    • One SQLite file per checkout, under the XDG cache directory, holding pages, blocks, references, aliases, and a content hash for every source file. A command opens the file, compares each source file's size and modification time with the recorded ones the way git status does, rehashes only the files that changed, reparses those, and then re-resolves the links whose targets those files could have changed. Git's index has used the size-and-mtime shortcut for decades, so it is a known quantity.
    • The re-resolving step is the one codekiln called pretentious when Codex first named it, so here it is plainly. After an edit the engine does two jobs: it re-reads the file that changed, and it re-checks links in other files whose target that change may have moved. 588fb79e docs: point nvim/Distro/LazyVim at LazyVim page removed alias:: [[nvim/Distro/LazyVim]] from the LazyVim page, and every [[nvim/Distro/LazyVim]] link in this garden changed target in a commit that edited none of the files holding those links. A lookup from each name to the blocks that reference it makes the second job a list walk.

  • What frontier performance means as a benchmark

    • The Brief already says budgets come from measurement on the encode garden. Frontier performance adds targets in the same terms: a warm garden page resolve finishes in about the time git status takes in this repository, editor completion returns before the next keystroke lands, and a cold parse of the encode garden is paid about once per checkout. Codex's benchmark rows measure all of those. The rows for repeated short-lived processes and for completion during a background parse are the ones that catch a tool that is fast in a demo and slow in a session.
    • The most useful row is one only codekiln can write. Name the operation that felt slow in Looksyk and the one that felt slow in Tine, on which graph, and make each a benchmark case. Measuring the new tool on the case that was slow in each is the way to know it does better.