Artifact fac31ac4aa0e50e23ffc84efa9b2604d86cf2667ae56ede32c773f8d0e9490d2:
- File
conformance/horizon_memo_test.go
-
2026-10-29 12:46:28
— part of check-in
[bfce209a24]
on branch perf/463-memo-trees
— perf(content): keep the memo's trees for the life of the memo
HZ-6.2-10 asks that an origin read each structural artifact's F cards once per store. The memo's tree index already kept fossil-scm.org's whole tree history in about 11MiB, yet it still read trees again in two cases: past a 64MiB bound, and after any full read of the store, which dropped the index with its lineage.
Neither was needed. A tree piece is what its name's bytes say, so it is valid in every store that holds the name; the rid it was read at is checked against the view's own rid-to-name map, and a renumbered store reads it once more and moves it to its rid. The index grows with the store like the reference graph beside it, so the byte bound goes; only a names bound at the most artifacts a classified store can hold remains, which one store cannot reach.
On the fossil-scm.org clone a horizon 2000 back after a full read now takes 1.0-1.8s instead of 4.3-6.2s, and the whole history after a full read reads no tree (1.3-1.5s, from 14-17s). Cold runs and peak heap are unchanged. HZ-6.2-10 is now covered; the trees still enter the graph when a walk first reaches them, as the reverted eager read cost 4-5x cold. (user: [email protected], size: 10551) [annotate] [blame] [check-ins using]
-
2026-10-29 14:58:28
— part of check-in
[dd58b95c70]
on branch main
— Merge pull request #527 from danmestas/perf/463-memo-trees
perf(content): keep the memo's trees for the life of the memo (HZ-6.2-10) (user: [email protected], size: 10551) [annotate] [blame] [check-ins using]
-
2026-10-29 12:46:28
— part of check-in
[bfce209a24]
on branch perf/463-memo-trees
— perf(content): keep the memo's trees for the life of the memo