Skip to content
Lightning YAML

Benchmarks

Speed, memory, and spec-conformance for Lightning YAML against the other parsers this repo benchmarks itself against: js-yaml, yaml (eemeli), and the JSON baseline where a workload is JSON-shaped enough for it to compete. Every chart below is a static image — inline SVG rendered at build time, no client JavaScript.

Measured on Intel(R) Xeon(R) Processor @ 2.80GHz (~1.53 GHz) · node 22.22.2 (x64-linux) · generated 2026-07-13 · source README.md@6b0c56e

These numbers are a hand-captured, representative snapshot — not a live feed. Once the CI benchmark job is wired up to publish runs to the benchmark-data branch, this page will read that history automatically and the charts will track it without further changes.

Parse time

Section titled “Parse time”

Parse time by workload

Lower is better. Bars are proportional to time; each workload is scaled to its own slowest parser (rows span microseconds to seconds, so compare bars within a row, not across rows). Avg wall time per parse() call.

  • JSON
  • js-yaml
  • yaml (eemeli)
  • Lightning YAML
Parse time by workload (avg, ns per iteration)Parse time by workload (avg, ns per iteration) — lower is better. Each workload is scaled to its own slowest parser, so bar length is proportional to time within a row; rows are not comparable to each other, and every bar is labelled with its exact value. Series: JSON, js-yaml, yaml (eemeli), Lightning YAML. 5 workloads: small-records, medium-records, large-records, xlarge-records, yaml-rich-medium.6.75 µs65.8 µs680 µs15.6 µssmall-records767 µs6.57 ms83.0 ms1.54 msmedium-records8.56 ms104 ms964 ms19.2 mslarge-records97.5 ms998 ms9.89 s196 msxlarge-records85.3 ms2.36 msyaml-rich-medium

A curated size progression (small through xlarge) plus one yaml-rich workload (anchors and !!binary, where only yaml and lightning-yaml can run at all) — the full 13-workload breakdown is in the summary table below.

Stringify time

Section titled “Stringify time”

Stringify time by workload

Lower is better. Bars are proportional to time; each workload is scaled to its own slowest parser (rows span microseconds to seconds, so compare bars within a row, not across rows). Avg wall time per stringify() call.

  • JSON
  • js-yaml
  • yaml (eemeli)
  • Lightning YAML
Stringify time by workload (avg, ns per iteration)Stringify time by workload (avg, ns per iteration) — lower is better. Each workload is scaled to its own slowest parser, so bar length is proportional to time within a row; rows are not comparable to each other, and every bar is labelled with its exact value. Series: JSON, js-yaml, yaml (eemeli), Lightning YAML. 5 workloads: small-records, medium-records, large-records, xlarge-records, yaml-rich-medium.4.48 µs130 µs368 µs18.8 µssmall-records529 µs15.5 ms41.0 ms2.42 msmedium-records7.43 ms202 ms443 ms35.6 mslarge-records66.9 ms1.90 s4.06 s539 msxlarge-records9.69 ms45.8 ms2.35 msyaml-rich-medium

Peak memory

Section titled “Peak memory”

Peak memory by workload (parse)

Lower is better. Bars are proportional to peak RSS; each workload is scaled to its own slowest parser, so compare bars within a row, not across rows. Peak resident set size, fixed at 25 iterations.

  • JSON
  • js-yaml
  • yaml (eemeli)
  • Lightning YAML
Peak memory by workload (parse, resident set size)Peak memory by workload (parse, resident set size) — lower is better. Each workload is scaled to its own slowest parser, so bar length is proportional to memory within a row; rows are not comparable to each other, and every bar is labelled with its exact value. Series: JSON, js-yaml, yaml (eemeli), Lightning YAML. 3 workloads: small-records, large-records, xlarge-records.91.2 MB95.5 MB101 MB92.9 MBsmall-records123 MB262 MB526 MB136 MBlarge-records284 MB975 MB2744 MB369 MBxlarge-records

Conformance

Section titled “Conformance”

YAML test-suite conformance

Higher is better. Pass rate across 373 cases from the official yaml-test-suite.

YAML test-suite conformance (pass rate)YAML test-suite conformance (pass rate) — higher is better. Lightning YAML 97.6%, yaml (eemeli) 97.1%, js-yaml 94.9%.0%25%50%75%100%Lightning YAML97.6% (364/373)yaml (eemeli)97.1% (362/373)js-yaml94.9% (354/373)

lightning-yaml passes 97.6% of the suite — including all 91 negative (should-fail) cases — ahead of yaml at 97.1% and js-yaml at 94.9%. Merge keys (<<), absent from the test corpus, are the only unimplemented construct.

Summary

Section titled “Summary”

Every parse-time workload, all four libraries, avg ns per iteration (— where a library can’t read that workload):

WorkloadJSONjs-yamlyaml (eemeli)Lightning YAML
small-records6.75 µs65.8 µs680 µs15.6 µs
medium-records767 µs6.57 ms83.0 ms1.54 ms
large-records8.56 ms104 ms964 ms19.2 ms
xlarge-records97.5 ms998 ms9.89 s196 ms
medium-nested1.51 ms11.8 ms130 ms2.94 ms
large-nested10.9 ms112 ms931 ms22.2 ms
yaml-plain-small-records—65.9 µs749 µs20.3 µs
yaml-plain-medium-records—7.78 ms103 ms2.44 ms
yaml-plain-large-records—112 ms1.01 s25.7 ms
yaml-plain-medium-nested—3.82 ms59.4 ms1.33 ms
yaml-rich-small——1.04 ms30.2 µs
yaml-rich-medium——85.3 ms2.36 ms
yaml-rich-large——1.18 s21.2 ms

Conformance, 373 cases from the yaml-test-suite:

LibraryPassedTotalScore
Lightning YAML36437397.6%
yaml (eemeli)36237397.1%
js-yaml35437394.9%