Repository navigation
Belt SCM capture: read each re-bound object shard once (recapture 30x re-read) - #13616
Closed
gunbai-bot[bot] wants to merge 2 commits into
Closed
gunbai-bot[bot] wants to merge 2 commits into
gunbai-bot[bot] wants to merge 2 commits into
Conversation
…once, not per path
The delta fold, the base advance and recapture each called materialize_if_rostered per
re-bound path; materialize_objects reads a whole shard to admit one member, so a shard
holding k re-bound objects was read k times (30x on srv2). The bytes are now read first
(one reader shared by tick worktree / committed revision / advance), the persisted
objects they may shadow are demanded together through one materialize_objects plan, and
the fold is pure. Deletes belt_scm_delta_fold_step{,_at_revision}; adds a plan control.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
… it) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Contributor
Author
|
review 78241: confirmed — I dropped the |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Chain re-derivation (DESIGN §6b)
Repeated demand originates in
belt_scm_delta_bind_text→belt_scm_delta_resident_for→materialize_if_rostered, called per re-bound path in the tick fold, the recapture (committed-revision) fold and the BaseAdvance fold.materialize_objectsreads a whole shard to admit one demanded member, so a shard holding k re-bound objects was read k times — matching srv2's 30/24/13 reads. The earliest boundary that re-demands: the per-path bind. The change population is known once its bytes are read.Fix (carry, not cache)
belt_scm_worktree_textsfor the tick;belt_scm_advance_textsfor recapture and advance).belt_scm_rebind_foldderives one demand from the whole population (belt_scm_rebound_identities) → onematerialize_objectsplan (dedups shards) → purebelt_scm_advance_fold.belt_scm_delta_fold_step,belt_scm_delta_fold_step_at_revision,belt_scm_delta_resident_for; tick and recapture now share one fold with the advance (shared mint ⇒ tick had the same defect, fixed together).Control
a_rebound_population_plans_each_shard_once: population demand = 1 shard; same identities one-at-a-time = k.Not verified here
No local build (CI-sized). The srv2 before/after Filesystem.Read counts and wall time still need a run of
belt_scm_recapture_clion srv2; remaining single-identity reads (tip/base root, candidate manifest if already persisted) are one each and unchanged. Relies on CI for compile + witnesses.🤖 Generated with Claude Code