Artifact Description [49fd77a1d4]

Artifact 49fd77a1d41667e09e445b97cfedf54b2217e5f6817437c30d9c3c5adef7fa35:

• File internal/content/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: 18040) [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: 18040) [annotate] [blame] [check-ins using]