fix: Shared-shell replay shifts 1 MiB on every output chunk - #1111
Closed
sam-saffron-jarvis wants to merge 1 commit into
Closed
fix: Shared-shell replay shifts 1 MiB on every output chunk#1111sam-saffron-jarvis wants to merge 1 commit into
sam-saffron-jarvis wants to merge 1 commit into
Conversation
Owner
|
Closing at the maintainer’s request in favor of a consolidated implementation on the current working tree (not merged or pushed yet). Retained as an 8/10 priority: batch shared-shell replay compaction rather than copying 1 MiB for every small PTY chunk. Includes offset/redaction/chunked replay coverage and an additional large-write-after-compaction regression. Full Go suite, relevant race tests, build, vet, and diff checks pass. |
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 changed
baseOffsetandnextOffsetsemantics.Why this is high-value
The Unix PTY producer reads up to 32 KiB at a time. Once the replay buffer reached 1 MiB, each ordinary output callback previously copied the entire retained window while holding the shell mutex. That meant about 32 MiB copied for each 1 MiB of continued output, delaying snapshots, browser input, lifecycle operations, and collaboration state during verbose builds, tests, searches, and log streams.
The logical prefix makes eviction constant-time per chunk and performs one roughly 1 MiB compaction per additional 1 MiB of output instead of one per 32 KiB chunk: 32x fewer replay-window shifts in the steady producer case. The end-to-end append benchmark improved from a median 520.8 ms (515 MB/s) to 425.3 ms (631 MB/s) for 256 MiB on an i9-14900K, while replay storage remains bounded to roughly two windows between compactions.
Validation
go test ./cmd -run '^TestServeShellReplay(ResetAndExit|CompactsDroppedPrefixesInBatches)$' -count=1go test -race ./cmd -run '^TestServeShellReplay(ResetAndExit|CompactsDroppedPrefixesInBatches)$' -count=1go test ./cmd -run '^$' -bench '^BenchmarkServeShellReplaySmallChunks$' -benchtime=1x -benchmem -count=3520768260 ns/op,515.46 MB/s425333161 ns/op,631.12 MB/sgo build ./...go vet ./...go test ./...ran successfully for the changedcmdpackage and all other root-module packages except an unrelated existing generated-frontend budget failure ininternal/serveui:app.jsgzip 138137 > 135000 andapp.cssgzip 33383 > 33000. This branch changes no frontend source or bundle-budget code.