Reduce graph refresh cost and isolate Hub construction - #180
Draft
theDakshJaitly wants to merge 3 commits into
Draft
Reduce graph refresh cost and isolate Hub construction#180theDakshJaitly wants to merge 3 commits into
theDakshJaitly wants to merge 3 commits into
Conversation
Align browser assertions with parsed-file progress, skip unused WASM initialization, and observe benchmark jobs through bounded SSE without status polling. Preserve existing resource budgets and record pinned Settings calibration evidence.
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.
What
Graph refresh can block the Hub while rebuilding the repository and spend minutes persisting fingerprints. Candidate construction now runs in a disposable Node process. The Hub keeps serving requests and owns the maintenance lease, validation, cancellation, and atomic publication of the last trustworthy graph.
CLI construction remains in process. Public declarations, graph schema, and grounding baselines are unchanged. Telemetry remains separate. This draft targets
codex/0.8.1; nothing is merged.Evidence and tradeoffs
Related to #140 and the Hub refresh investigation. This does not claim reproduction or resolution of the reporter's private repository.
On the same frozen 723-file MEX corpus, the baseline engine took 305.712 s and this implementation took 71.046 s, about 4.3× faster in one ordered local pair. Native statement preparations fell from 426,415 to 117. All 12 normalized tables and four ranked search queries matched; integrity and foreign-key checks passed.
The actual Hub completed an edited-source refresh in 92.107 s. Job polling p95 was 3.944 ms, and cancellation was acknowledged in 8.036 ms while preserving the prior graph. Combined sampled RSS still peaked around 1.9 GiB, and synchronous initial/validation/publication boundaries caused pauses up to 5.238 s. There is no peak-memory quota; fatal parent termination can leave owned temporary artifacts.
Process isolation has a real startup/memory cost. An identical-code local four-file diagnostic measured 879.5 ms per isolated rebuild versus 220.2 ms in a warm process. Aggregate peak RSS increased 321 → 404 MiB, while surviving-parent RSS decreased 320 → 164 MiB. This bounded Mac diagnostic explains the tradeoff; it is not calibration evidence or a universal memory guarantee.
Two independent pinned Linux runners confirmed five small-fixture Graph timing regressions. Their explicitly accepted limits use the first healthy corrected report and the existing
ceil(p95 * 1.15)formula: small refresh/rebuild 1634/1689 ms, medium 1842/1820 ms, large rebuild 2278 ms. Large refresh and all memory limits remain unchanged. Prior limits, both raw sample sets, runner identities, hashes, and unowned-budget guards are retained.See implementation and verification, large-repository measurements, isolation diagnostic, and pinned timing calibration.
Validation
4d6683epassed full Node 22/24, browser, and Windows/macOS portability CI. Its two-run performance gate confirmed only the five timing failures above; repeated memory crossings remained advisory under the unchanged rules.c93f09d. The independent performance allocations measured the same synthetic mergecdfb07300a91f0b76771281e0acdeba6ed2110a3and produced no final violations. Large Wiki rebuild prompted confirmation, then measured 628.167 ms with zero samples above its existing 709.55 ms material threshold; its 617 ms budget remains unchanged.Checklist
c93f09d(run34291831733)main— intentionally targetscodex/0.8.1under the release plan