Repository navigation
Add a time bound to the UpgradeRoots pass - #97
Merged
Merged
Conversation
Options.UpgradeTimeFactor stops the pass after factor times the first solve's duration; Options.UpgradeMaxTime is an absolute cap. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merged
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.
Adds an opt-in time bound to the
UpgradeRootspass so a hard list cannot spend several times its base solve in the pass.Options.UpgradeTimeFactor: stop starting re-solves once the pass has run for factor x the first solve's duration (thisResolvecall). 0 = no bound.Options.UpgradeMaxTime: absolute cap. 0 = none. The tighter bound wins.now, test-onlySetClock), so tests use a fake clock, no sleeps.With a bound set the answer can vary with machine load, only on lists where the bound is reached. Defaults are unchanged.
Tests (fake clock, each solve takes 10s): factor 0.5/1/1.5/2/50/+Inf stop after the expected number of re-solves and keep the best so far;
UpgradeMaxTime; combined bounds; bound spent before the first re-solve returns the base answer; repeated runs identical; factor 0 unchanged. Red first (did not compile: new fields andSetClockmissing).Checked:
go test ./...and-racepass; vet, gofmt, golangci-lint clean. packse 147 = 94/2/6/4/41, SAT oracle 102 with 8 disagreements, ecosystem 165 pins, transcript unchanged.Quality benchmark (114 + 111 sets, 2853 + 2731 cells): factor 1.0 keeps all of the pass's gains on both corpora; factor 0.5 keeps them too (main: roots 3+ behind 33 -> 6 at 0, 1.0 and 0.5; versions behind per cell 2.97 -> 2.41/2.41/2.38; h2: 10 -> 0 at all three, 1.60 -> 0.13). Pass cost on main (sum of per-cell seconds): 25 base, 40 unbounded, 32 at 1.0, 29 at 0.5; slowest cell 5.8s -> 4.2s -> 3.0s. The h2 timings are noise-level.
RoboRev job 5243: no findings. Merged origin/main (v0.22.0, #96) in 4649b26; CHANGELOG entry kept under Unreleased;
go test -race ./...and golangci-lint pass on the merge; RoboRev job 5247: no findings.Independence audit (
audit.sh --paths '%go-pyresolver-worktrees/upgrade-time%', afteragentsview sync): PASS, exit 0. 1 authoring session, 225 in the lineage, no known reference retrieved. Cross-repo note: 2curldownloads of the uv release binary by a dogfood session in the lineage (a binary, not source).🤖 Generated with Claude Code