Optimization index
A scorecard of the optimizations we investigated, generated from the optimization block in each
research note below — so it can’t drift from them. Each row links to the full note.
Verdicts: promising — a real win, adopted or worth adopting; situational — a genuine win that carries a tradeoff, so it lives behind an opt-in; inconclusive — measured but no clear end-to-end signal; not-worth-it — evaluated and rejected (kept for the record so we don’t re-litigate it). Pure reference/ceiling analyses (e.g. the codegen speed ceiling) are browsable notes but are not scored here.
| Optimization | Conclusion | Verdict |
|---|---|---|
| Block-scalar ConsString accumulator (parse) | Accumulating block-scalar text with a ConsString (`res +=`) instead of `parts.push`/`join` targets the function owning ~47% of self-time on multiline records, for an estimated high-single-digit to ~15% parse-CPU cut on block-scalar-heavy YAML. | Promising |
| Map-key render cache (stringify) | Memoizing each map key's rendered "key:" string removes a repeated quote-classification and per-row concatenation, and is the single largest lever found on the dump side. | Promising |
| String value interning (parse) | Deduplicating repeated string values during parse is a real, parity-safe retained-heap reduction on repetitive record arrays, but it costs measurable parse speed, so it belongs behind an opt-in flag. | Situational |
| One-scan scalar-style classifier (stringify) | Folding the dumper's up-to-three separate scans of each quoted string into one PLAIN/SINGLE/DOUBLE classifier is ~1.8x faster in isolation, but the end-to-end payoff on string-heavy data was not conclusively measured. | Inconclusive |
| Array-join vs ConsString rope (stringify) | Replacing the `out += ...` ConsString rope with an array-of-chunks + `join` is 4-11% slower on four of five fixtures, so the current rope is kept. | Not worth it |
| Columnar store + proxy facade (memory) | A struct-of-arrays columnar store is genuinely compact, but the per-row proxy facade needed to keep the plain-object API costs more memory than the objects it replaces and slows reads. | Not worth it |
| Hand-rolled formatNumber (stringify) | `formatNumber` looks costly in profiles but is near-irreducible — `String(v)` is already V8's optimal shortest round-trip and the best fast-path saves under 1% of dump time. | Not worth it |
| Hand-rolled number parsing (parse) | Number conversion is ~18% of parse self-time but already sits on V8's native floor; a hand-written JS float parser is slower and loses precision. | Not worth it |
| Input-length pre-parse gate (parse) | Reading `input.length` before parsing is free but the setup it could skip is already tiny, so as a standalone change it buys almost nothing — it earns its keep only as a size-gate for a heavier optimization. | Not worth it |
| Object.freeze on parsed output (memory) | Freezing the parsed tree saves no memory, costs ~28% more to build and ~3.9x slower reads, and breaks the mutable-output contract — at most an opt-in for immutability, never a memory optimization. | Not worth it |
| Single-pass optimistic dumper (stringify) | An optimistic single write pass that skips the mandatory ref pre-scan and restarts only on a shared reference reproduces byte-identical output and gains +5-48% on tree-shaped data, but it was built and then removed: the dual-path restart machinery was not worth its cost given ~1.6-1.9x regressions on large graphs whose first shared reference appears late, so the two-pass pre-scan is retained. | Not worth it |
| Tiny-document fixed overhead (parse) | The fixed per-call parse cost is real but small, has no single dominant removable component, and only bites sub-microsecond documents outside the target workload. | Not worth it |