Artifact Description [ff64a8b052]

Artifact ff64a8b0527e300273c7bc25d75cc7059980193620b9692f601e7ca467bdf901:

• File internal/sync/horizon_memo.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: 3979) [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: 3979) [annotate] [blame] [check-ins using]