feat: halve the record buffer now the store holds the backlog - #41
Merged
Conversation
The ring is sized in records, so doubling the message cap doubled its cost. Four records is enough to absorb a burst logged while the service task is sending; the store, not the ring, is what holds a backlog. Flash +11,980 B (unchanged) RAM +7,384 B (-2,056) Log stack +704 B (unchanged) Service +992 B (unchanged) Static RAM is the only figure that moves, and it is exactly four records at the cap plus a two-byte length prefix each. Nothing else is affected: the ring bounds how many records can be in flight, not how large one may be. Taken with the cap rise, the pair costs 248 bytes. The ring ends up 8 bytes smaller than it was before the cap moved — four records at 512 is less than eight at 256 — so what is actually being paid for is the store's single record buffer, which follows the cap and cannot be halved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe syslog circular buffer is reduced from eight records to four. README stage costs, aggregate resource deltas, and the generated run report are updated for the smaller-ring configuration. ChangesSmaller ring stage
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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.
Pull request
What this stage adds
The ring is sized in records, so doubling the message cap doubled its cost. Four
records is enough to absorb a burst logged while the service task is sending; the
store, not the ring, is what holds a backlog.
Flash +11,980 B (unchanged)
RAM +7,384 B (-2,056)
Log stack +704 B (unchanged)
Service +992 B (unchanged)
Static RAM is the only figure that moves, and it is exactly four records at the cap
plus a two-byte length prefix each. Nothing else is affected: the ring bounds how
many records can be in flight, not how large one may be.
Taken with the cap rise, the pair costs 248 bytes. The ring ends up 8 bytes smaller
than it was before the cap moved — four records at 512 is less than eight at 256 —
so what is actually being paid for is the store's single record buffer, which
follows the cap and cannot be halved.
Files
Checklist
measurements/buffer-halve.csvcommitted.measurements/stages.tsv.python3 scripts/gen-cost-table.py../run.shgreen (build + QEMU + baseline self-check) —run-report.mdcommitted.Context for review: 14 of 21 sequential single-commit PRs replaying the integration on top of the Baseline root. Each lands green and reviewed before the next is built on it, because a change to an early commit would force every commit above it to be re-run and re-measured.
Summary by CodeRabbit
Improvements
Documentation