Performance

How oneyaml-csharp compares with the other .NET YAML libraries on speed and memory. Every task runs on the same inputs for every library, through the oneyaml benchmark kit, oneyaml-kit. The tables and charts below are generated from the kit's result file; none of the numbers is typed by hand.

The figures are measured, not bounds: they hold for the workloads, versions and host named in the method line of each block. A run that is marked as not publishable is a smoke result; it shows the layout and the rough picture, and it is not a claim.

What is compared:

• Loading and writing, typed and untyped, against YamlDotNet, SharpYaml and VYaml. oneyaml-csharp is measured on both its reflection path and its generated-metadata path.
• Reading a document for editing, and editing it, against the closest .NET equivalents, such as SharpYaml's syntax tree.
• Applying a patch against Yaml2JsonNode with JsonPatch.Net, the usual .NET route for a JSON Patch on YAML. That route converts to a JSON tree and does not keep the file's formatting, so the comparison is of the work, not of equal output.

Each generated table names the competitors of every task, and a cell without a number says why.

The kit's benchmark notes define each task and how it is timed. The kit also decides when a difference in time or memory is too small to call a win or a loss; the verdict rules say where those bands lie and how a verdict is reached.

Results at a glance

One row per task: our time and the strongest competitor's, each the geometric mean over the task's workloads, with the verdict and the method of the run. The chart in the README is drawn from these rows.

Not in a row's mean: patch (RFC 6902): no competitor answer: compose-wordpress, gha-workflow.

Each row is the geometric mean, over the real-world workloads the task has, of our time and of the time of the strongest competitor in each workload. Speed is the competitor's time divided by ours: 2× faster means half the time, and a loss is stated as slower. Where several competitors were strongest the column names them all, with how often. A † marks a cell measured differently from the task as specified; the note beside each mark says how. A marked competitor still counts. A workload where our library has no number is listed and the row is marked as partial, never counted as a win. The verdict is never better than the per-workload verdicts allow: a row with a losing workload is marked mixed or loss, and a row with no winning workload is never marked a win. The speed is over the real-world workloads. The verdict is never better than the real-world workloads allow, nor better than all of the task's workloads allow, generated and reference ones included: a loss on any of them keeps a row from being a clean win and the row says how many it lost, and a win on them cannot lift a row the real-world workloads do not win. Memory and the count of better, level and worse workloads in each row are on the full page.

Method: full run of 2026-10-18T00:48:41Z. Kit 0.1.0 (revision 6cc83d12fbc6); text generated by kit revision c1647a46aa6d. oneyaml-csharp c23a19250217; competitors yamldotnet 18.1.0, sharpyaml 3.16.0, sharpyaml-model 3.16.0, sharpyaml-syntax 3.16.0, vyaml 1.4.1, yaml2jsonnode 3.0.1, oneyaml-csharp-gen c23a19250217. Runtime .NET 10.0.11 (target linux-x64), measured with BenchmarkDotNet 0.15.8: mean time per task from BenchmarkDotNet's ShortRun job (3 warm-up and 3 measured iterations) run in process; one invocation per iteration runs a batch of prepared tasks and the time is divided by the batch size; every cell is measured in a process of its own, because the heap that earlier cells leave behind changed the result. Each process runs with DOTNET_TC_CallCountingDelayMs=0 (call counting starts immediately instead of after the default delay), and no other DOTNET_ or COMPlus_ variable set, and every cell is first warmed up for 1000 ms of whole batches before BenchmarkDotNet's own warm-up, because a new process starts at the runtime's unoptimised tier. Memory: bytes allocated per task from BenchmarkDotNet's MemoryDiagnoser; allocation calls are not available. AMD Ryzen 9 7950X3D 16-Core Processor (125.0 GiB), Linux 7.0.0-34-generic (x86_64), measured on a shared workstation (32 logical CPUs; load 3.72 before, 4.52 after, at most 8.48 during).

Results

Every task and workload, time and memory, from the same run.

Time per operation

Allocated bytes per task (MemoryDiagnoser)

Cells without a number, with what the correctness guard found:

1. sharpyaml (rejects; generic-load ×2, dump ×2): Stops at its default nesting limit, which the benchmark leaves as it is. What the guard found, in generic-load on deep-block: default limit, not raised: YamlException: The maximum nesting depth of 64 has be…
2. sharpyaml (differs; dump ×4): Writes a float with no fractional part (812.0) as 812, so a YAML 1.2 reader reads it back as an integer. What the guard found, in dump on records-4k: read back: at /1/score: got 812, expected 812.0
3. sharpyaml-model (differs; dump ×1): What the guard found, in dump on unicode-32k: read back: at /2: got "Ø3DÞ00 grin 0", expected "\uD83D\uDE00 grin 0"
4. sharpyaml-model (differs; dump ×1): What the guard found, in dump on long-scalars-256k: read back: at /folded: got "epsilon zeta psi omega delta xi epsilon mu beta theta rho alpha psi delta delta…, expected "epsilon zeta psi omega delta xi epsilon mu beta theta rho alpha psi delta delta…
5. sharpyaml-model (differs; dump ×1): What the guard found, in dump on gha-workflow: read back: at /jobs/test-output/steps/2/run: got "echo \"Commit: ${{ steps.checkout.outputs.commit }}\"\necho \"Ref: ${{ steps.ch…, expected "echo \"Commit: ${{ steps.checkout.outputs.commit }}\"\nec…
6. sharpyaml-model (rejects; generic-load ×2, dump ×2): Stops at its default nesting limit, which the benchmark leaves as it is. What the guard found, in generic-load on deep-block: default limit, not raised: YamlException: The maximum nesting depth of 64 has be…
7. sharpyaml-syntax (rejects; document-parse ×2, unchanged-emit ×2): Stops at its default nesting limit, which the benchmark leaves as it is. What the guard found, in document-parse on deep-block: default limit, not raised: YamlException: The maximum nesting depth of 64 has be…
8. vyaml (differs; dump ×1): What the guard found, in dump on long-scalars-256k: read back: at /folded: got "epsilon zeta psi omega delta xi epsilon mu beta theta rho alpha psi delta delta…, expected "epsilon zeta psi omega delta xi epsilon mu beta theta rho alpha psi delta delta…
9. vyaml (differs; dump ×3): A string that ends with a newline reads back without that final newline. What the guard found, in dump on reference-a: read back: at /b: got "this is a test", expected "this is a test\n"
10. vyaml (differs; dump ×4): Writes a float with no fractional part (812.0) as 812, so a YAML 1.2 reader reads it back as an integer. What the guard found, in dump on records-4k: read back: at /1/score: got 812, expected 812.0
11. vyaml (differs; dump ×1): Writes a string that looks like a number (05509, 1.5) without quotes, so it reads back as a number. What the guard found, in dump on helm-ingress-nginx: read back: at /defaultBackend/image/tag: got 1.5, expected "1.5"
12. yaml2jsonnode (differs; patch ×8): Patches a JSON tree and writes it back as YAML, so comments, blank lines and quoting are not kept (it is not lossless). What the guard found, in patch on compose-wordpress: byte 20: got 694 bytes ":\n db:\n image: \"mariadb:11.4\"\n ", expected 860 bytes ":\n db:\n # We use a mariadb image"
13. yamldotnet (rejects; dump ×2): Stops at its default nesting limit, which the benchmark leaves as it is. What the guard found, in dump on deep-block: default limit, not raised: MaximumRecursionLevelReachedException: Too much recur…
14. yamldotnet (differs; dump ×4): Writes a float with no fractional part (812.0) as 812, so a YAML 1.2 reader reads it back as an integer. What the guard found, in dump on records-4k: read back: at /1/score: got 812, expected 812.0

Relative figures are ours ÷ the strongest competitor in that row, so below 1.0× is better for us and ▼ marks a loss. A † marks a cell measured differently from the task as specified; the note beside each mark says how. Cells without a number say why. The verdict of a task in the chart and the first table is never better than the real-world workloads allow, nor better than all of the task's workloads in these tables allow, generated and reference ones included, while its speed figure is over the real-world workloads.

Method: full run of 2026-10-18T00:48:41Z. Kit 0.1.0 (revision 6cc83d12fbc6); text generated by kit revision c1647a46aa6d. oneyaml-csharp c23a19250217; competitors yamldotnet 18.1.0, sharpyaml 3.16.0, sharpyaml-model 3.16.0, sharpyaml-syntax 3.16.0, vyaml 1.4.1, yaml2jsonnode 3.0.1, oneyaml-csharp-gen c23a19250217. Runtime .NET 10.0.11 (target linux-x64), measured with BenchmarkDotNet 0.15.8: mean time per task from BenchmarkDotNet's ShortRun job (3 warm-up and 3 measured iterations) run in process; one invocation per iteration runs a batch of prepared tasks and the time is divided by the batch size; every cell is measured in a process of its own, because the heap that earlier cells leave behind changed the result. Each process runs with DOTNET_TC_CallCountingDelayMs=0 (call counting starts immediately instead of after the default delay), and no other DOTNET_ or COMPlus_ variable set, and every cell is first warmed up for 1000 ms of whole batches before BenchmarkDotNet's own warm-up, because a new process starts at the runtime's unoptimised tier. Memory: bytes allocated per task from BenchmarkDotNet's MemoryDiagnoser; allocation calls are not available. AMD Ryzen 9 7950X3D 16-Core Processor (125.0 GiB), Linux 7.0.0-34-generic (x86_64), measured on a shared workstation (32 logical CPUs; load 3.72 before, 4.52 after, at most 8.48 during).

Writing a document back

The unchanged emit rows time YamlDocument.ToUtf8Bytes() on a document that was not edited, and each call returns a new array. Where another library writes a file back faster, its unchanged emit row in Results is marked ▼ loss, and the verdict in Results at a glance counts it. Most of the time in those rows is the operating system supplying fresh memory pages for the new output array right after a garbage collection, and every library in the run pays that cost the same way (the kit's .NET harness notes describe it). That is what this run measured on this host, not a bound.

If you write large documents again and again, WriteTo(IBufferWriter<byte>) and WriteTo(Stream) write into a buffer you own and reuse, so they do not allocate a new output array on every call the way ToUtf8Bytes() does (Input, output and lifetime). The benchmarks do not measure those calls, so this page has no figure for them.

Running the benchmarks yourself

The published numbers come from the kit, which runs every library on the same workloads. To measure a checkout of this repository there, set KIT_ONEYAML_CSHARP_SRC to it and follow the kit's benchmark notes.

This repository also has BenchmarkDotNet benchmarks in bench/OneYaml.Benchmarks, used while developing; their README says how to run them. Their results are not the published ones.