Artifact Description [b6fbb27f72]

Artifact b6fbb27f7246fe318aa30f78659a8130e6874766d308b9689e692f50d1c15e05:

• File src/cmd/sync.zig
  • 2026-08-24 16:41:27 — part of check-in [1234842809] on branch index-borrow-143 — logstore: adopted index entries slice the blob instead of copying it

    Adopting a scan index duplicated every entry hash: 255,167 allocations and copies on a 348MB store to answer, typically, one lookup. The hashes are fixed-length slices of a buffer that was being freed at the end of the open, so the store now holds that buffer for its lifetime and the entries point into it. Opening tcl drops 44.0ms -> 37.5ms; smaller stores scale down with the index.

    openReadOnlyIndexed takes the blob UNCONDITIONALLY -- on success the store frees it in deinit, on every refusal it frees there. The first cut transferred only on success, both call sites looked right, and the second one double-freed inside commit's autosync. No type and no unit test caught it; only e2e did. A conditional transfer makes every call site restate the rule.

    Ownership is a prefix, not a per-entry flag: adopted entries come first and a tail resume appends owned ones after them, so borrowed_entries is the split point deinit and the batch rollback both read.

    The unit test pins that the hashes lie INSIDE the held blob, not merely that they compare equal -- equal bytes prove nothing about where they live, and a future dupe would restore the cost with every assertion still green.

    This is one part of #143. The CRC that issue names as the largest fixed cost measures 5.2ms of the 44ms (1,860 MB/s over the 9.7MB index), so it is not where the time goes and its integrity check should stay.

    Refs #143 (user: dmestas, size: 614747) [annotate] [blame] [check-ins using]

  • 2026-08-24 16:50:26 — part of check-in [3c3f936632] on branch trunk — merge index-borrow-143: adopted index entries slice the blob (#143) (user: dmestas, size: 614747) [annotate] [blame] [check-ins using]