kepr / 5bf8e3824f4a

countManifestLines/countFileLines now cache each object-backed file's line count keyed by its content hash (new object_line_counts table, added to both schema.sql and the idempotent EXTENDED_SCHEMA_SQL forward-migration) — since hashes are content-addressed, a hash's line count never changes, so a save that re-references an already-counted file skips the decompress+scan entirely instead of redoing it on every single save. This was likely the single largest lock-held cost per complete() call, scaling with total repo size rather than diff size. Binary files (NUL in first 512 bytes) cache as 0 so they're not re-scanned either. Added a regression test that tampers with an object's on-disk bytes between two saves sharing the same hash and confirms the second save's line count still comes from the cache, not a fresh (and now-wrong) decompress. Verified with a real throwaway Postgres: 636/639 pass, same 3 pre-existing failures as baseline, new test passes. Bump to v1.56.210

dev · 5 weeks ago · 2026-07-16 · 15.1 MB

session: phase B object line-count cache · agent: claude-sonnet-5

parent: 95f8a88b21f8