Performance

What every layer of oneyaml costs against the other Rust YAML libraries, on a fixed, generated corpus of configuration-file shapes. Coming from the chart in the README? Results at a glance has the same comparison bar by bar and as tables (five workloads against the fastest feature-complete serde library or yaml-edit, in instructions and in wall-clock time) and says where oneyaml wins and where it loses; Regenerate has the commands that produce every table here.

This page covers:

• the parser: oneyaml-syntax's lossless event stream against saphyr-parser, yaml-rust2, libyaml and yaml-edit, and its syntax tree (Parser);
• serde: reading (Serde read) and writing (Serde write) against serde_yaml_ng, serde_norway, serde-saphyr and serde_yaml2, with serde_json as a reference;
• Document: parse, emit and edits against yaml-edit (Document).

How to read these numbers

• The primary metric is CPU instructions, counted by valgrind (callgrind), per input byte (Ir/B) or per operation. Instruction counts are deterministic for a given build: repeated runs of the same binary give the same count (to within 0.1% where a hash map with per-process random keys is involved), so a difference between two cells of one run is real, not noise. Rebuilding (a different toolchain, or a dependency rebuilt with other code generation) can shift a library's counts by a few percent, so compare numbers from one run, as every table here does. Counts cover user-space work only, not cache misses, page faults or kernel time.
• Allocations (blocks, bytes, peak heap) are counted by valgrind DHAT and are deterministic too.
• Wall-clock times are informational. They were taken on a shared, loaded 16-core desktop (each wall-clock table prints the load average), so read them as ratios and orders of magnitude. Where wall-clock and instructions point in different directions, both are shown.
• Ratios are oneyaml ÷ competitor in these tables, so below 1.0× oneyaml is cheaper. The summary tables in Results at a glance and the README chart invert them into "× faster" (competitor ÷ oneyaml, higher is better).
• Serde ratios are against the fastest feature-complete library on each row: serde_yaml_ng, serde_norway and serde-saphyr all support aliases, multi-document streams and merge keys. serde_yaml2 does not (no multi-document API, no merge keys); its column and ratio are shown, marked partial, no target, but it never decides a verdict.
• Every competitor's output is checked before it is measured (the correctness-guard tables): a library that rejects an input, gives a different result, or can't do the equivalent work gets a rejects, differs or n/a cell instead of a number.

The run's provenance (the summary's method notes are read from it):

Results at a glance

The numbers behind the README chart: five workloads for each operation, each serde row against the fastest feature-complete serde library on that row and each Document row against yaml-edit, the other lossless editor. The chart has one bar per row; the tables give the absolute cost of both libraries, the instruction ratio and the wall-clock ratio, and label every row where oneyaml is slower slower. Both are generated from the per-operation tables further down this page, so they always match them.

• × faster = the competitor's CPU instructions ÷ oneyaml's on the same input (higher is better; below 1.0× oneyaml is slower), counted by valgrind (callgrind): deterministic from run to run, not wall-clock time. Ir/B = instructions per input byte; the edit script counts one script of three edits (insert + set + remove) on the parsed document; lower is better, the better value in bold.
• × faster (wall-clock) = the competitor's median time ÷ oneyaml's on the same host (for serde, from the median throughput); it varies more from run to run than the instruction count. oneyaml is slower in wall-clock time on 2 of 20 rows: serde read openapi-100k; Document edit script (insert + set + remove) compose-merge. The medians are equal on 2 rows: serde read gha-workflow and compose-merge.
• Measured oneyaml 1.2.0 release tree on 2026-10-21 · AMD Ryzen 9 7950X3D 16-Core Processor · Ubuntu 26.04 LTS (x86_64) · rustc 1.97.1 (8bab26f4f 2026-07-14) · valgrind-3.27.1, against serde_yaml_ng 0.10.0, serde_norway 0.9.42, serde-saphyr 1.3.0, yaml-edit 0.3.2. Serde rows compare with the fastest feature-complete YAML serde library on that row (aliases, multi-document, merge keys), Document rows with yaml-edit, the other lossless editor; every output is checked for equivalent work. Inputs are generated in the shape of GitHub Actions, docker-compose, Helm, OpenAPI and multi-document Kubernetes files.

Where oneyaml wins

• Parsing. The lossless event parser uses fewer instructions per byte than saphyr-parser, yaml-rust2 and libyaml on every input, comment- and whitespace-heavy ones included, although it does more work: it also produces events for every comment, space and indicator. Against yaml-edit, the other lossless parser, it is cheaper on every input yaml-edit accepts (Instructions).
• Serde writes. to_string uses fewer instructions than every feature-complete writer on every input, typed and untyped (Serde write).
• Serde reads use fewer instructions than the fastest feature-complete reader on every typed row, every value row but one (compose-merge, at parity) and most sparse rows, and stay within the 1.25× target on every row (Serde read; the targets are in Targets and results).
• Document. Parsing a Document costs fewer instructions than yaml-edit's parse on every input, although oneyaml's parse also checks the document's meaning (duplicate keys, merge keys, aliases) and yaml-edit's checks syntax only. Writing an unchanged document back is several times to an order of magnitude cheaper, byte-identical on every input, and a parsed document keeps less memory than yaml-edit's tree (Document).
• Edits stay local. The edit script on a root mapping costs about the same number of instructions on every input from 2.4 KB to 10 MB but helm-values, where yaml-edit's script grows with the document: openapi-10m, the openapi-100k shape at 100× the size, costs oneyaml about the same as openapi-100k (Edits). helm-values costs more per script because each edit there decides the owners of a long run of comment lines. The tables measure the size of the document, not the width of the edited mapping: a patch reads the keys of each mapping it looks at once per patch, so its cost does grow with the width of those mappings.
• Allocations. The parser borrows from the input and decodes scalars on request, so it makes a handful of allocations per input where event parsers make one or more per event; serde reads into borrowing types stream with O(depth) state (Allocations, serde allocations).
• No pathological input. oneyaml's instruction count grows linearly with input size on every stress shape, including 512k levels of flow nesting, which saphyr, yaml-rust2 and yaml-edit reject (Linear scaling).

Where oneyaml loses or is at parity

• Edits on documents below a few kilobytes (compose-merge, 2.4 KB) cost more than yaml-edit's, in instructions and in wall-clock time: each edit has a fixed cost for deciding which entry owns each nearby comment and checking that the edited text still reads as the tree says, which exceeds yaml-edit's whole-document cost on a small file. On every larger input in the Edits tables oneyaml's script is the cheaper one, so among the measured inputs the loss is on the smallest file.
• In wall-clock time, typed serde reads of openapi-100k are slower than serde_yaml_ng, although they use fewer instructions. Across the full table, serde reads are slower in wall-clock time on most sparse rows, on value reads of compose-merge, k8s-multi and openapi-100k and on that typed row, and at parity on typed reads of gha-workflow and compose-merge (serde wall-clock). If wall-clock read speed is what matters most to you, measure on your own data.
• sparse reads (a struct that reads a few fields) of the OpenAPI inputs take a few percent more instructions than serde_norway, and k8s-manifest's are at parity with serde_yaml_ng: oneyaml still resolves and checks the content a struct ignores (duplicate keys, merge keys), so a typed read accepts exactly the documents a Value read accepts (Instructions).
• value reads of the file with merge keys (compose-merge) are at parity in instructions with serde_yaml_ng.
• In wall-clock time, parsing anchors is slower than libyaml and flow-heavy is at parity, although both use fewer instructions (Wall-clock).
• In wall-clock time, value writes of compose-merge are slightly slower than serde-saphyr's, although they use fewer instructions (serde write wall-clock).
• serde_yaml2 is cheaper than oneyaml on the rows it can run, and serde_json reading the equivalent JSON is several times cheaper than any YAML library; both do less work (see their columns).

Targets and results

The performance targets oneyaml holds itself to, and how the tables below measure them. "met" means every row of the measure is within the target.

Regenerate

You need valgrind 3.27 or later on PATH (or pass --valgrind PATH) and, for the wall-clock tables, a machine as quiet as you can get.

cargo build -p bench --release
target/release/bench update docs/performance.md --timeout 300    # every table (~24 min with --jobs 4)
target/release/bench update docs/performance.md --section wall   # one section
target/release/bench table scaling                               # print a table, don't write
target/release/bench probe yaml-edit deep-flow 10                # one parser, one input
target/release/bench serde-check serde_yaml2 value gha-workflow  # one read-guard verdict
target/release/bench ser-check serde-saphyr typed k8s-multi      # one write-guard verdict (+ output bytes)
target/release/bench probe serde:oneyaml:typed openapi-10m 1     # one serde read probe
target/release/bench probe ser:oneyaml:typed openapi-10m 1       # one serde write probe
target/release/bench probe doc:yaml-edit:script openapi-100k 1   # one Document probe
target/release/bench readme                                      # summary and README charts only, from the tables below

• Tables come from the default release build, the one users compile oneyaml and the comparators with, so every library's numbers are the ones its users get. update and table refuse any other build, and a build with an override they can see: an optimization level other than 3, any CARGO_PROFILE_* variable in the build's environment (the bench profile's included: cargo build --profile bench writes to target/release too), or RUSTFLAGS. They can't see overrides passed with --config or set in a Cargo config file, so don't measure with those. The environment table's Build row records the build.
• Comparing oneyaml with itself (probe counts before and after a change) can use the measure profile instead: cargo build -p bench --profile measure, then target/measure/bench probe …. In a release build, how the compiler splits code into codegen units moves some counts by up to about 1% when unrelated code changes; the measure profile builds in a single codegen unit, which removes that. It also changes how every library is optimized: on every serde read row, serde_yaml_ng's counts rise by about 6% to 14% and serde-saphyr's by about 2% to 6%, while oneyaml's move by about 1% or less. That would flatter oneyaml's ratios, so probe and time run from it, and update and table don't.
• Every table sits between <!-- bench:NAME:begin/end --> markers. update rewrites only what's between them, one section at a time (every section, in document order, without --section), and writes the file after each section, so don't edit it while update runs.
• --jobs N limits how many valgrind processes run at once (default: every core). --timeout SECS (default 100) kills a probe that runs too long; wall-clock children get a quarter of it. These tables used 300: at 100, libyaml's deep-flow at 100× and yaml-edit's deep-flow at 10× time out instead of finishing.
• The summary and the README chart are generated from this file. After every update, and on its own with bench readme (which measures nothing), bench rewrites the bench:summary tables and chart in Results at a glance, the chart and its link in the bench:readme region of crates/oneyaml/README.md and the bench:chart region of the repository README.md, and the charts docs/img/bench-{summary,detail}-{light,dark}.svg, from the serde-instructions, ser-instructions, document and edits tables, their wall-clock tables and the environment table. Every number in them is a cell of those tables or the ratio of two, so the READMEs can't disagree with this file.
• The environment table records the run's revision, date, CPU, OS, rustc, build, valgrind and the comparator versions (from Cargo.lock). update re-records it whenever it re-measures a table the summary reads. --revision TEXT, --revision-note TEXT and --date YYYY-MM-DD override what it records.
• Releases pin the links. The READMEs' chart URLs and links to this file name a git ref, main by default. A published crate's README is frozen at release, so a release runs cargo run -p bench --release -- pin-links <tag> on the release commit to point every repository link of the published docs at the tag (--dry-run shows what would change), and pin-links main afterwards to point them back.

How long each section took in this run (--timeout 300 --jobs 4):

valgrind 3.27.1 was built from source (https://sourceware.org/pub/valgrind/valgrind-3.27.1.tar.bz2, sha256 5d589152eb8071c02feab8ce6ab719e431a1fbc3e2b1700f5432632a8b9264dc) with ./configure --prefix=$HOME/.local && make && make install.

Method

Instructions. The bench binary runs itself as bench probe <parser> <case> <scale> under valgrind --tool=callgrind --toggle-collect=*measured_drain*. Only instructions executed while the measured function is on the stack are counted: the parse (or read, write, edit), consuming the whole output, and dropping it. Input generation and start-up are excluded. This is the iai-callgrind/gungraun technique without their runner.

Allocations. valgrind DHAT (--tool=dhat) reports total blocks, total bytes and the heap peak (t-gmax) of the whole probe. A baseline probe generates the same input and does nothing else; its blocks and bytes are subtracted from each probe's, which leaves exactly the measured work's allocations (a realloc counts as one). The peak can't be subtracted, because the baseline's peak happens during input generation, so peak tables show the whole-process peak ÷ input with the baseline beside it.

Wall-clock. bench time runs one child process per library and input, one after another: one validating run, one warm-up, then at least 5 and at most 1,000 timed runs, stopping once 300 ms have been spent. Tables show the median.

Linear scaling. Every parser runs each stress shape at 1×, 10× and 100× of 10 KB (about 1 MB at 100×), measured in instructions. A cell is (Ir_k / bytes_k) / (Ir_1 / bytes_1); 1.00 is perfectly linear, and a ratio above 1.25 would be flagged SUPERLINEAR.

Failures are cells. Every measurement runs in a child process, so a library that errors, crashes or hangs becomes a rejects, crash or timeout cell, not a failed run. Every corpus input is valid YAML 1.2, and a test checks that oneyaml accepts it.

Isolation. The competitors are reached only through the unpublished oracles crate; no published oneyaml crate depends on any of them (cargo tree shows none of them in any published crate's graph).

Corpus

crates/bench/src/corpus.rs generates every input from templates written for this project. There is no third-party text, so the corpus is license-clean and versioned with the code; the FNV-1a column shows when a generator changes. The real-world shapes follow the public structure of each format; they aren't copies of real files:

• Kubernetes (k8s-manifest, and k8s-multi with over a thousand documents): Deployment, Service, ConfigMap and Ingress, as Helm renders them.
• GitHub Actions (gha-workflow): on, env, matrix jobs, uses/with, and run: |/>-.
• docker-compose (compose-merge): x- extension fields with &anchors, and <<: *merge keys.
• OpenAPI 3.1 (openapi-100k, openapi-10m): paths with parameters, responses and $refs, plus components/schemas.
• Helm values (helm-values): an umbrella chart's values.yaml documented the helm-docs way (# -- lines), with commented-out example blocks; about 70% of its bytes are comment lines.

The synthetic stress shapes (deep-block, deep-flow, wide-map, long-scalars, block-scalars, flow-heavy, comment-heavy, anchors, whitespace) appear at 10× (about 100 KB) in the deterministic tables.

size_of::<oneyaml_syntax::Event>() = 48 bytes.

Parser

What each parser does

Every column consumes its parser's complete output for the whole input; no parser has an event cap, and none renders anything.

They do different work. oneyaml and yaml-edit are lossless: they keep every byte, including comments and whitespace. saphyr, yaml-rust2 and libyaml throw that away, so on the same input oneyaml's stream has 2–5× more events (see the corpus table's event counts).

Settings. oneyaml runs under Settings::new().limits(Limits::unlimited()): the default max_depth of 1,024 would reject deep-flow at every scale and deep-block at 100×. The limit checks still run; they just never trip. The competitors run with their defaults. saphyr and yaml-rust2 hold the flow level in a u8, so they reject flow nesting deeper than 255; yaml-edit rejects deep-block from 10× and deep-flow at every scale; libyaml rejects whitespace, which has a tab after - (valid in YAML 1.2).

Instructions

Lower is better. The ratio columns compare oneyaml with the fastest of the three event parsers, and with yaml-edit.

Allocations

Allocation count (blocks, realloc included; baseline subtracted)

Bytes allocated ÷ input bytes (baseline subtracted)

Whole-process peak heap ÷ input bytes (the baseline column is input generation alone)

Collecting (parse_with)

What keeping the whole stream costs: oneyaml-collect runs parse_with (an EventList, 48 bytes per event) and walks it, against the pull parser dropping each event. DHAT peak heap and bytes allocated, net of the input-generation baseline, divided by the input size.

Syntax tree (SyntaxTree::parse_with)

What the lossless syntax tree costs. oneyaml-tree builds the tree from the pull parser (the tree owns a copy of the input, as a Document does), walks every element, and drops it; oneyaml-tree-retained keeps the built tree, so DHAT's end-of-run figure is exactly what a tree retains. Both are divided by the input size and include the tree's own copy of the input (1.00×). "peak" is the whole-process peak minus the heap the baseline still holds at its end (the generated input). The arena stores 9 bytes per element, so retained ≈ 1 + 9 × elements ÷ byte; the densest synthetic shapes, where nearly every byte is its own element, retain the most. "stream Ir/B" is the pull parser drained; "tree Ir/B" is parse + build + walk + drop.

Linear scaling

Wall-clock (informational only)

Real-world inputs run at 1× and stress shapes at 100× (about 1 MB). Higher MB/s is better. The ratio columns are time ratios, so lower is better for oneyaml.

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 5.72 / 7.78 / 8.81. MB/s = 10⁶ bytes/s, median of ≥ 5 runs.

Each stress shape's throughput at 1×, 10× and 100× (10 KB, 100 KB and 1 MB):

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 5.60 / 7.09 / 8.44. MB/s = 10⁶ bytes/s, median of ≥ 5 runs.

Serde read

Comparators, pinned in crates/oracles/Cargo.toml:

serde-saphyr's default resource budget rejects k8s-multi (more than 1,024 documents) and openapi-10m (more than 250,000 nodes and 1,000,000 events), inputs oneyaml's Limits::default() accepts, so it runs with those three caps lifted and every other budget check on. The saphyr project's own saphyr-serde crate is still a placeholder; serde-saphyr is a third-party crate built on a fork of saphyr-parser.

Workloads, each on every real-world corpus input at 1×:

• value: every document into the library's dynamic value type;
• typed: every document into realistic derived structs (crates/bench/src/models.rs: Kubernetes objects as a kind-tagged enum with an untagged IntOrString; a GitHub Actions workflow; a compose file whose services get restart/logging/networks from <<: *common; an OpenAPI document with nested schemas; Helm values read through #[serde(flatten)]);
• sparse: every document into a struct that reads a few fields and skips the rest.

oneyaml runs with Settings::new() (so Limits::default(), unlike the parser tables), plus merge_keys on compose-merge.

serde_json reads the equivalent JSON (oneyaml's Value of each document, merges expanded, serialized compactly and cached so the probe reads a file). It is a reference ceiling, not a YAML comparator: JSON has no plain scalars to resolve, no indentation and no anchors. Its Ir/B and MB/s are per byte of the YAML input.

Metrics: callgrind instructions inside the measured function (deserialize every document, then drop the result); DHAT totals minus a baseline probe that only prepares the input; the whole-process DHAT peak ÷ input beside the baseline's; and wall-clock medians.

Correctness guard

Before anything is measured, bench serde-check <lib> <workload> <case> runs oneyaml and the competitor, converts every document of both results to serde_json::Value, and compares them. A competitor that differs, rejects or can't do the equivalent work is not measured on that row; the reason is listed under the table. Two notes on the reasons: serde_yaml2 reads the quoted scalar "1.85" as a float, where YAML 1.2 (and 1.1) make it a string; and serde_json rejects gha-workflow typed because in the JSON equivalent RUST_BACKTRACE: 1 is a number, while every YAML library reads the plain scalar 1 into a String from its source text. The second is a property of JSON as a reference, not a disagreement between YAML libraries.

1. serde_yaml2, k8s-manifest value: no multi-document API (reads the first document only)
2. serde_yaml2, k8s-manifest typed: no multi-document API (reads the first document only)
3. serde_yaml2, k8s-manifest sparse: no multi-document API (reads the first document only)
4. serde_yaml2, gha-workflow value: doc 0 /jobs/bravo-2/strategy/matrix/toolchain/2: 1.85 (ours "1.85")
5. serde_json, gha-workflow typed: invalid type: integer '1', expected a string at line 1 column 845
6. serde_yaml2, compose-merge value: no merge-key support
7. serde_yaml2, compose-merge typed: no merge-key support
8. serde_yaml2, compose-merge sparse: no merge-key support
9. serde_yaml2, k8s-multi value: no multi-document API (reads the first document only)
10. serde_yaml2, k8s-multi typed: no multi-document API (reads the first document only)
11. serde_yaml2, k8s-multi sparse: no multi-document API (reads the first document only)

Instructions

Lower is better. The ratio columns compare oneyaml with the fastest feature-complete library on that row (named in the next column; the target applies to this ratio), with serde_yaml2 (partial, no target), and with serde_json.

Allocations

Allocation count (blocks, realloc included; baseline subtracted)

Bytes allocated ÷ YAML input bytes (baseline subtracted)

Whole-process peak heap ÷ YAML input bytes (the baseline column is YAML generation alone)

Wall-clock (informational only)

Higher MB/s is better (per byte of YAML input, also for serde_json); the ratio columns are time ratios, lower is better for oneyaml.

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 7.57 / 7.76 / 8.36. MB/s = 10⁶ bytes/s, median of ≥ 5 runs.

Serde write

The same comparators, each through its own writer with its defaults:

to_writer is to_string plus one write_all of the result, so it is not a separate row. Every side uses its default settings (oneyaml's quotes every string that some YAML reader would read as something else).

Workloads, each on every real-world corpus input at 1× (every document):

• value: every document as the library's own dynamic value, read beforehand by that library (serde_json: from the equivalent JSON), so each library writes its natural in-memory form;
• typed: every document as the derived structs of crates/bench/src/models.rs, read beforehand by oneyaml, so every library writes the same Rust values.

Reading the data is preparation, outside the measured function (write, then drop the output); each cell's DHAT baseline prepares the same data and writes nothing.

Correctness guard (write)

bench ser-check <lib> <workload> <case>: each library writes its data, and the output is read back with oneyaml's reader (serde_json's for serde_json), into Value for value (compared with oneyaml's reading of the input) or into the same structs for typed (compared with ==). A library whose output reads back as something else (a lost or extra document, a changed scalar type, an escape that doesn't read back, an empty collection turned into null) is differs and is not measured; oneyaml is checked the same way. An agrees cell also shows the output size ÷ the input size.

1. serde_yaml2, k8s-manifest value: no multi-document API (writes one document only)
2. serde_yaml2, k8s-manifest typed: no multi-document API (writes one document only)
3. serde_yaml2, gha-workflow value: output does not read back: a ''' inside a single-quoted scalar ends it early at jobs.delta-0.steps[2].with (81:48)
4. serde_yaml2, gha-workflow typed: output does not read back: a ''' inside a single-quoted scalar ends it early at jobs.bravo-2.steps[2].with (95:48)
5. serde_yaml2, compose-merge value: no merge-key support
6. serde_yaml2, compose-merge typed: output does not read back: invalid type: unit value, expected a map at services.db.environment (75:18)
7. serde_yaml2, k8s-multi value: no multi-document API (writes one document only)
8. serde_yaml2, k8s-multi typed: no multi-document API (writes one document only)
9. serde_yaml2, openapi-100k value: doc 0 /components/schemas/delta0/properties/ratio/example: 0 (ours 0.0)
10. serde_yaml2, openapi-100k typed: output does not read back: invalid type: unit value, expected a map at paths./alphas/107/{id}.parameters[0].schema.properties (37:20)
11. serde_yaml2, openapi-10m value: doc 0 /components/schemas/delta0/properties/ratio/example: 0 (ours 0.0)
12. serde_yaml2, openapi-10m typed: output does not read back: invalid type: unit value, expected a map at paths./alphas/10011/{id}.parameters[0].schema.properties (37:20)
13. serde_yaml2, helm-values value: doc 0 /alpha11/affinity: null (ours {})
14. serde_yaml2, helm-values typed: output does not read back: invalid type: unit value, expected a map (1:1)

Instructions (write)

Lower is better; columns as in the read table.

Allocations (write)

Allocation count (blocks, realloc included; baseline subtracted)

Bytes allocated ÷ YAML input bytes (baseline subtracted)

Peak heap added by writing ÷ YAML input bytes (whole-process peak minus the baseline's, which holds the prepared data)

The third table replaces the read path's whole-process peak: the baseline's peak is the prepared data, so the difference is what writing adds at its peak, the output plus the writer's working set. ≤ prep means writing never rose above the preparation's peak, so DHAT can't tell what it added. This table has no ratio columns: a hidden cell could be below any visible one.

Wall-clock (write, informational only)

Higher MB/s is better (MB of YAML input, for every library); the ratio columns are time ratios.

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 11.69 / 10.09 / 9.18. MB/s = 10⁶ bytes/s, median of ≥ 5 runs.

Document

yaml-edit 0.3.2 is the comparator: the other lossless YAML editor for Rust. Both sides run on the real-world corpus at 1×; oneyaml under the default settings with Limits::unlimited(), as in the parser tables.

• parse: oneyaml Stream::parse_with(input, &settings), the strict entry point (a single-document input costs the same through Document::parse_with): the syntax tree plus the meaning check, so that Document::parse fails exactly where from_str::<Value> fails (duplicate keys, merge values, aliases, tags). yaml-edit: YamlFile::parse, which checks syntax only. The result is dropped; neither side walks it.
• emit: to_string() of the parsed, untouched document (parsing is preparation, not measured). The emit = input column checks that the output is byte-identical to the input, for both libraries.
• retained: parse, then keep the result, so DHAT's end-of-run heap (net of the baseline's) is what a parsed document keeps, including its own copy of the input. parse blocks are the allocations of a parse.

Instructions (Ir/B; lower is better)

Memory (DHAT; parse allocations net of the input-generation baseline; retained = the parsed stream/file kept, net of the baseline's end-of-run heap, including the parser's copy of the input where it keeps one)

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 9.18 / 9.66 / 9.09. Median of ≥ 5 runs, in ms.

Wall-clock (informational only)

Edits

yaml-edit has a comparable edit API (Document::set/remove on its rowan CST).

• script: a fixed script on the first document's root mapping: insert a new last entry bench_edit_key: x, replace its value with 'y', remove it, on a parsed document (parsing is preparation, not measured). oneyaml: Stream::document_mut(0), insert, set_path, remove; yaml-edit: Document::set twice, Document::remove. The instruction columns are totals for one script on a fresh parse, not per byte: a local edit should cost the same at any document size. The script leaves the document as it found it, so the wall-clock columns repeat it on one tree.
• round: parse + script + to_string, from the input text.
• output: = when the text after the round is byte-identical to the input.

Instructions (lower is better)

Host: AMD Ryzen 9 7950X3D 16-Core Processor; load average (1/5/15 min) at start: 10.72 / 9.90 / 9.20. Median of ≥ 5 runs, in ms.

Wall-clock (informational only)