Record why the control-plane performance cuts exist and how to harvest them - #9
Merged
Merged
Conversation
…t them. Each Datahazed perf PR is a separate cut. This file is the decision record for submitting them to get-bb: goal, how we arrived at it, what we rejected, product benefit, tests that fail if the slow path returns, and submit order.
This was referenced Sep 2, 2026
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.
Human comments
What was wrong
The Datahazed performance PRs (#1–#8) each say what changed. They did not, together, record why we started, how we chose these cuts instead of a router rewrite, who in core bb benefits, or in what order to submit them to get-bb.
What changed
Added
docs/perf-control-plane.md: goal (first paint; do not block Node on sync SQLite), how we arrived at it (live isolated Electron vs T3, traced send → remount → skeleton), each cut’s why/how/benefit/test, what we rejected, and harvest order.No runtime change.
Why this way
Code comments are forbidden in this repo except tool directives. The harvest record has to live in a doc and in PR bodies that can be copied to get-bb. This file is the index; each code PR’s body is still self-contained.
Benefit to bb
Anyone deciding whether to take these patches upstream can read one page instead of reconstructing the T3 comparison and the remount trace.
Harvest
Documentation only. Do not merge this file to get-bb unless they want the notebook; copy the relevant section into the get-bb PR body instead.
How you verified
Read through against Datahazed PRs #1–#8 and the existing get-bb openings get-bb#2931, get-bb#2934, get-bb#2935, get-bb#2936.