Artifact 707aa257c3ec50a8675f05a9416de1e6ea4b57d4a5b84e84a8f06b8316a00244:
- File
internal/content/cone_reference_budget.go
-
2026-10-22 22:31:27
— part of check-in
[62ffc8ff92]
on branch feat/horizon-cones
— perf(sync): extend the memo by the arrivals' metadata alone
Measured on a dense 68k-artifact, 21k check-in repository, a horizon pull after a one-artifact push still spent most of its time scanning every blob's metadata to extend the memo, and a structural request extended it twice: once to place the horizon ahead of the request's transaction, unpublished, and again inside it.
An extension now carries the artifact names over and reads metadata only for the arrivals and the delta ancestors their reads expand. A structural request places its horizon in a read-only transaction of its own, a committed snapshot, and publishes that view, so the inventory finds the memo current.
TestCorpusHorizonPullAfterPush (LIBFOSSIL_CORPUS) times it: a pull after a one-artifact push goes from about 2.7s to 0.2s for a content horizon, and from about 4.4s to 0.3s for a structural one. (user: [email protected], size: 15520) [annotate] [blame] [check-ins using]
-
2026-10-22 22:48:31
— part of check-in
[7dec3e4fb3]
on branch feat/horizon-cones
— Merge branch 'wip/hz-memo' into feat/horizon-cones
The origin's classification memo (draft-fossil-horizon-00 ยง6.2): the reference graph and each cone's classification kept per store prefix and extended by appended artifacts, recomputed in full only when an arrival was already cited. A pull after a one-artifact push on fossil-scm.org's repository answers in about 0.25 s instead of 2.7 to 4.5 s. (user: [email protected], size: 15520) [annotate] [blame] [check-ins using]
-
2026-10-22 22:31:27
— part of check-in
[62ffc8ff92]
on branch feat/horizon-cones
— perf(sync): extend the memo by the arrivals' metadata alone