Owned engine: a batch scales linearly at about a millisecond per edit
What was measured
On 2026-09-13, Go 1.27.1, Ryzen 7 5825U, one core, against keryx-init.yaml (12 KB) at d4beefe:
| Operation | yamldoc | yaml.v3 node API |
|---|---|---|
| parse, set one key, emit | 5.3 ms, 2.8 MB | 0.6 ms, 0.3 MB |
| ten keys in one batch | 14.0 ms, 9.7 MB | 0.6 ms |
| a hundred keys in one batch | 47.7 ms, 37 MB |
Parsing the 43 KB manifest costs 5.6 ms against yaml.v3's 1.6 ms and goccy's 3.5 ms; Project to native values costs 11.6 ms against 1.9 ms. The harness and full output are in the comparison report.
Where the time goes
Each command inside Edit builds a complete new working syntax revision (ReviseScalar, ReviseSubtree, ReviseInsertion, ReviseRemoval each copy the tree), and every tx.Snapshot() between commands composes semantics lazily but from scratch for the new revision, so a batch is linear in edits with a constant of roughly a millisecond on a 12 KB file. Publication then re-parses and re-composes the candidate once, which is the checked-transaction cost and is not the linear part. The previous session's handover recorded the same shape on a synthetic 1000-entry, 100-command benchmark (653 MB allocated after an earlier 1.18 GB).
Directions, not a prescription
- Share unchanged subtrees between working revisions rather than copying the whole tree per command; the node records are already immutable, so structural sharing is the natural fit.
- Reuse the previous working revision's semantic composition for subtrees the command did not touch.
- Consider batching consecutive scalar commands into one revision when no read intervenes.
- Parse-side: the 2.1 MB and 19k allocations for a 43 KB file suggest the token and node records are worth a look independently of editing.
None of this changes behaviour; the checks stay. Not for the owned-engine MR; a follow-up once it has merged and the consumer path is in use, so the measurements have a real workload behind them. The docs page already states the cost plainly, so this is a performance improvement, not a correctness fix.