Performance

This page compares the time and memory of oneyaml-go with those of the other Go YAML libraries. Every library runs the same tasks on the same inputs, through the benchmark of oneyaml-kit, the kit shared by the oneyaml libraries. The tables under Results are generated from the kit's result file, and none of their numbers is typed by hand. The summary at the top of the README is generated from the same file.

The figures are measured, not bounds. They describe these inputs on this machine, and your files and hardware will give other numbers.

About this run

• Library: oneyaml-go 1.0.0. The figures are for the code released as v1.0.0, at commit eea67bb; the tag sits on a later commit that changes no library code. This page is generated again from a new run at each release.
• Competitors: go.yaml.in/yaml/v3, the maintained fork of yaml.v3 (yaml-v3 in the tables), go.yaml.in/yaml/v4 (yaml-v4), gopkg.in/yaml.v2 (yaml-v2), sigs.k8s.io/yaml (sigs-yaml) and github.com/goccy/go-yaml (goccy-go-yaml). For patches, they are github.com/palantir/pkg/yamlpatch with its yaml.v3 back end (palantir-yamlpatch) and with its goccy/go-yaml back end (palantir-yamlpatch-goccy), and github.com/evanphx/json-patch/v5 on top of sigs.k8s.io/yaml (json-patch). The method line under each table gives the exact versions.
• Machine and date: a full run on 2026-10-16, on a shared workstation, not a reserved machine. Other work ran on it at the same time, and the method line under each table records the host's load before the run, after it and at its highest during it. The cells run one after another, so a busy moment slows only the cells measured during it, ours or a competitor's; weigh a close result with that in mind. The method line also gives the CPU, the operating system and the Go version.
• Kit: revision 0abba1d. The kit's benchmark notes at that revision describe the method in full. This page summarises them.

What is measured

Tasks

Each task starts from a state that is built outside the clock, fresh for every iteration, with one exception. In unchanged emit, a write can take nanoseconds, so a library whose write of a used document allocates the same as a write of a fresh one shares one parsed document between iterations. oneyaml-go's write allocates nothing either way. The timed work is what a caller of the library does.

The competitors do the same work through their own APIs. For the document tasks that means yaml.v3's and yaml/v4's Node and goccy/go-yaml's AST. In the Go harness, every library's patch is timed from text to text: read the file, apply the patch, and write the text back. A library that cannot do a task at all, such as a library with no lossless document, gets an "unsupported" cell, which is not a loss.

Workloads

The inputs are real files, vendored byte for byte with their source and licence: a GitHub Actions workflow, a Compose file, Helm chart values, two OpenAPI descriptions, a multi-document Kubernetes manifest and a Prometheus configuration. Generated inputs add typed records, Compose files with anchors and merge keys, Kubernetes streams, OpenAPI and Helm-style documents and a flat wide mapping at several sizes, and stress shapes: deep nesting, long scalars of every style, flow-heavy data, anchors and aliases, Unicode, and every scalar style and chomping mode. Two small reference cases edit a block scalar. The kit's notes at the run's revision list them under Workloads.

The expected values do not come from any of the libraries being measured. A generated input and its value come from the same generator. A real file's value is accepted only when two independent YAML 1.2 parsers agree on it. The expected bytes after an edit are exact text substitutions on the input.

The correctness check before timing

Each library's answer is checked before it is timed. A library gets a number only if its answer was right. A wrong answer is marked "differs" and a refused input is marked "rejects", and neither carries a time or a memory figure. The report of the run lists every such cell with the first difference the check found. See the correctness guard in the kit's notes at the run's revision.

Time and memory

The time is the ns/op that Go's testing.Benchmark reports, so it is a mean over the iterations of the benchmark. In a full run each cell runs for Go's standard benchtime of one second. The memory figures are the bytes and allocations per operation that testing.B reports with ReportAllocs. They count what was allocated during the timed work, not the peak size of the heap.

Reading the tables

Each row compares oneyaml-go with the strongest competitor in that row: the fastest for time, and the one that allocated least for memory. The ratio is our figure divided by theirs, so below 1.0× is better for oneyaml-go. A small gap counts as a tie (the kit's verdicts at the run's revision give the bands: under 5% for time and 2% for memory), and a loss is marked ▼.

A note in parentheses after a time names the answer a competitor was checked against when it is not the plain one. (merged) means it applied << merge keys while loading, a YAML 1.1 extension, and was checked against the merged value; YAML 1.2, and oneyaml-go by default, read << as an ordinary key. Such a cell did different work from ours and is still compared with. (value-only) is explained by the † below.

A † marks a cell that was not measured on exactly the task as specified, for example json-patch, which works on JSON and so cannot keep the text of the file. It is still compared with. In this Go run every patch cell carries a † for "text API", ours included: every library's patch is timed from the input text to the output text, and the palantir-yamlpatch cells passed the same byte-for-byte check as ours, so that mark does not mean less work. Only the "value-only" json-patch cells were judged more loosely. So on a patch cell in this run, a † says how the cell was measured, not that it did less work.

The README summary takes, for each task, the geometric mean over the real-world files that task has. It states the ratio the other way round, as how many times faster oneyaml-go was: the competitor's time divided by ours, so higher is better there. The tables below show every workload.

Unchanged emit

The unchanged-emit ratio is much further below 1.0× than that of any other row, and it does not measure how fast oneyaml-go renders YAML. A Document keeps the text it parsed. Bytes on a document that was not edited returns that text without copying it, so its cost does not grow with the size of the file. The competitors build their text again from a Node tree or an AST. The task measures what a caller pays to write back a file they did not change, which is a real use, but the gap comes from not rendering, not from rendering faster. For the time it takes to write YAML from values, see the dump row. For the time an edit takes, including writing the result, see the edit-script row.

Rows with no rival

A row says "no rival" when oneyaml-go gave a correct answer and no competitor did. There is no comparison in such a row, so it is not a win and it is not counted as one. In this run those rows are:

• document parse, unchanged emit and edit script on several real files and generated inputs: the competitors' documents did not write the input back byte for byte. They changed blank lines, indentation, quoting or escapes, or the layout of a flow collection. In the edit script on the reference-b case, goccy/go-yaml also wrote the edited block scalar as a plain scalar, so the text lost its style.
• dump on the typed-records inputs: the text the competitors wrote did not read back to the expected value. For example, a float with a whole-number value came back as an integer, or a string of digits lost its quotes and came back as a number.
• patch on the GitHub Actions workflow: the competitors' output differed from the expected bytes, or the patch was refused.

The report of the run gives the first difference for each of these cells.

Reproducing the run

From a checkout of oneyaml-kit at the revision above, with KIT_ONEYAML_GO_SRC set to a checkout of this repository at v1.0.0:

bin/bench run --mode full --lang go
bin/bench readme --results out --library oneyaml-go --readme <oneyaml-go>/README.md --docs <oneyaml-go>/docs --charts docs/img

The first command writes the result file, a report with every cell and charts under out/bench. The second writes the generated blocks of this page and of the README, and the README's charts. The blocks on this page were written by bin/bench readme at the run's kit revision, from that result file. A full run is a result wherever it runs, and its method line says what kind of machine it ran on and, for a local machine, the host's load. A quick run, or a run started with --smoke, is labelled a smoke result. It shows the layout and the rough picture but it is not a claim, and bin/bench readme refuses it unless you pass --allow-smoke, which labels every block.

Results

Time per operation

Allocated bytes per operation (B/op)

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

1. goccy-go-yaml (differs; edit-script ×1): Does not keep the block literal style of the edited value: the new text is written as a plain scalar. What the guard found, in edit-script on reference-b: byte 26: got 48 bytes "#abc 123\nb: this is a test2\nc: 13\n", expected 53 bytes "#abc 123\nb: |-\n this is a test2\nc: "; line 5: got "b: this is a test2", expected "b: |-"
2. goccy-go-yaml (differs; document-parse ×6, unchanged-emit ×6, edit-script ×7): The AST prints its own spacing for flow collections and trailing comments, and blank lines, quoting or a leading --- marker change, so the text it writes back is not the input. What the guard found, in document-parse on compose-wordpress: does not write the input back: byte 807: got 807 bytes "\n db_data:\n", expected 815 bytes "\n db_data:\n\n \n "; the texts differ only in blank lines
3. goccy-go-yaml (differs; dump ×4): 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 records-4k: read back: at /14/address/zip: got 5509, expected "05509"
4. goccy-go-yaml (differs; document-parse ×1, unchanged-emit ×1): Writes the escapes of a double-quoted scalar (\u00e9) as the characters themselves. What the guard found, in document-parse on unicode-32k: does not write the input back: byte 20: got 28160 bytes " café 0\n- \"é中文 0\"\n- \"😀 grin", expected 32800 bytes " café 0\n- \"\\u00e9\\u4e2d\\u6587 0\"\n- "; line 2: got "- \"é中文 0\"", expected "- \…
5. goccy-go-yaml (differs; document-parse ×4, unchanged-emit ×4, edit-script ×4): Writes the null spelled ~ as null. What the guard found, in document-parse on records-4k: does not write the input back: byte 736: got 4275 bytes ".25\n note: null\n- id: 3\n name: Eps", expected 4242 bytes ".25\n note: ~\n- id: 3\n name: Epsilo"; line 47: got " note: null", expected…
6. json-patch (rejects; patch ×1): Reads the document through sigs.k8s.io/yaml, a YAML 1.1 reader: the key on is the boolean true, so a path under /on is not found. What the guard found, in patch on gha-workflow: add operation does not apply: doc is missing path: "/on/push/branches/-": missin…
7. json-patch (differs; patch ×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 patch on records-4k: value after the patch: at /1/score: got 812, expected 812 (float)
8. palantir-yamlpatch (differs; patch ×1): Does not keep the block literal style of the edited value: the new text is written as a plain scalar. What the guard found, in patch on reference-b: byte 13: got 47 bytes "hello\na: 10\n#abc 123\nb: this is a te", expected 53 bytes "hello\na: 10\n\n#abc 123\nb: |-\n this i"; line 3: got "#abc 123", expected ""
9. palantir-yamlpatch (differs; patch ×3): Patches through the yaml.v3 node tree, which keeps comments but not blank lines, spacing or a leading --- marker, so the text it writes back differs from the input. What the guard found, in patch on compose-wordpress: byte 852: got 852 bytes "\n db_data:\n", expected 860 bytes "\n db_data:\n\n \n "; the texts differ only in blank lines
10. palantir-yamlpatch-goccy (differs; patch ×1): Does not keep the block literal style of the edited value: the new text is written as a plain scalar. What the guard found, in patch on reference-b: byte 26: got 48 bytes "#abc 123\nb: this is a test2\nc: 13\n", expected 53 bytes "#abc 123\nb: |-\n this is a test2\nc: "; line 5: got "b: this is a test2", expected "b: |-"
11. palantir-yamlpatch-goccy (differs; patch ×2): Patches through the goccy AST, which prints its own spacing and changes blank lines, so the text it writes back differs from the input. What the guard found, in patch on compose-wordpress: byte 852: got 852 bytes "\n db_data:\n", expected 860 bytes "\n db_data:\n\n \n "; the texts differ only in blank lines
12. palantir-yamlpatch-goccy (differs; patch ×4): Writes the null spelled ~ as null. What the guard found, in patch on records-4k: byte 752: got 4244 bytes ".25\n note: null\n- id: 3\n name: Eps", expected 4211 bytes ".25\n note: ~\n- id: 3\n name: Epsilo"; line 48: got " note: null", expected " note: ~"
13. sigs-yaml (differs; typed-load ×1, generic-load ×1, dump ×1): A YAML 1.1 reader: the key on is the boolean true, so /on is not found. What the guard found, in typed-load on gha-workflow: /on/push/branches: 0 items, expected 2
14. sigs-yaml (differs; dump ×1): A YAML 1.1 reader: the plain scalar y is the boolean true. What the guard found, in dump on anchors-32k: read back: at /base/b/1: got true, expected "y"
15. sigs-yaml (differs; generic-load ×3): Reads one document of a multi-document stream, so the stream does not come back whole. What the guard found, in generic-load on k8s-ingress-nginx-multi: at /: got a mapping of 3, expected a sequence of 19
16. sigs-yaml (differs; generic-load ×19): Reads through JSON, where every number is a float, so an integer comes back as a float. What the guard found, in generic-load on compose-wordpress: at /services/db/expose/0: got 3306 (float), expected 3306
17. sigs-yaml (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 (float)
18. yaml-v2 (differs; generic-load ×1, dump ×1): A YAML 1.1 reader: the key on is the boolean true, so /on is not found. What the guard found, in generic-load on gha-workflow: missing /on
19. yaml-v2 (differs; generic-load ×1, dump ×1): A YAML 1.1 reader: the plain scalar y is the boolean true. What the guard found, in generic-load on anchors-32k: at /base/b/1: got true, expected "y"
20. yaml-v2 (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 (float)
21. yaml-v3 (differs; document-parse ×18, unchanged-emit ×18, edit-script ×11): The yaml.Node tree keeps comments but not blank lines, spacing or a leading --- marker, and it lays flow collections out its own way, so the text it writes back is not the input. What the guard found, in document-parse on compose-wordpress: does not write the input back: byte 807: got 807 bytes "\n db_data:\n", expected 815 bytes "\n db_data:\n\n \n "; the texts differ only in blank lines
22. yaml-v3 (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 (float)
23. yaml-v4 (differs; document-parse ×24, unchanged-emit ×24, edit-script ×16): The yaml.Node tree keeps comments but not blank lines, spacing or a leading --- marker, and it lays flow collections out its own way, so the text it writes back is not the input. What the guard found, in document-parse on compose-wordpress: does not write the input back: byte 303: got 783 bytes "olumes:\n - db_data:/var/lib/mysql", expected 815 bytes "olumes:\n - db_data:/var/lib/mys"; the texts differ only in blank lines and in…
24. yaml-v4 (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 (float)

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.

Method: full run of 2026-10-16T21:48:45Z. Kit revision 0abba1d8b4f2. oneyaml-go eea67bb6b962; competitors yaml-v3 v3.0.5, yaml-v4 v4.0.0-rc.6, yaml-v2 v2.4.0, sigs-yaml v1.6.0, goccy-go-yaml v1.19.2, palantir-yamlpatch v1.5.0, palantir-yamlpatch-goccy v1.5.0, json-patch v5.9.11. Runtime go1.26.0 (target linux/amd64), measured with testing.B: ns/op from testing.Benchmark at benchtime 1s. Memory: B/op and allocs/op from testing.B (ReportAllocs). 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 2.67 before, 4.06 after, at most 11.23 during).