Benchmarks

hyperlark builds its parse tables at runtime (like chevrotain and tree-sitter) — it does not generate code. So its natural peers are other runtime parsers, not codegen parsers (nom, lalrpop, pest) or specialized native parsers (JSON.parse), which sit in their own tiers. Every measurement is like-for-like: each parser produces and reads the same value (the JSON object, or the evaluated calc result) through its natural pipeline.

For a per-language, head-to-head comparison against the main parsing libraries — what each one is, its trade-offs, and when to prefer it — see Alternatives, which charts hyperlark’s LALR and Earley engines against the field in Rust, Python, JS, and C.

Note

Trust ratios, not absolute milliseconds — one shared runner. Pick your language below. The tabs are sticky and sync with the code-example tabs elsewhere, except WASM: what is measured is the wasm binding rather than a language, so it has no code-example tab to pair with.

Python

The Python hyperlark is the PyO3 binding over the same Rust core: you call it from Python, but the parse runs in native code — only your transformer callbacks cross back. So its peers are the other Python parsing libraries. Every one here computes the same scalar (JSON: the sum of truncated numbers; calc: the evaluated result) and the outputs are compared, with any disagreement reported, so the times are like-for-like.

Both engines, one chart. hyperlark’s LALR and Earley appear together so you can see what the general engine costs you. lark’s own Earley is left out here — at 1056 and 1568 ms it would flatten everything — and gets its own comparison at the bottom of this tab.

JSON → value (Python, 134 KB)

hyperlark (LALR) 4.85 ms

sly 43.4 ms

lark (LALR) 52.6 ms

hyperlark (Earley) 66.1 ms

parsimonious (PEG) omitted at 201 ms — it would flatten the chart; it is in the table, and in the Earley comparison at the foot of this tab.

calc → number (Python, 85 KB)

hyperlark (LALR) 7.05 ms

sly 39.8 ms

hyperlark (Earley) 69.5 ms

lark (LALR) 70.8 ms

parsimonious omitted at 127 ms, for the same reason.

lark is the pure-Python reference implementation hyperlark reimplements — the parity baseline, on the same grammars. sly is a yacc-style LALR generator that reduces straight to a value, so every library here is measured that way: an embedded transformer, no tree on either side. The three are doing the same shape of work. parsimonious is a PEG library — general, and charted with the other general engines at the foot of this tab. hyperlark wins because the parse itself is native Rust.

Every library, both workloads (ms; JSON 134 KB, calc 85 KB — the bench corpus):

library	JSON → value	calc → number
hyperlark (LALR)	4.85	7.05
sly	43.4	39.8
lark (LALR)	52.6	70.8
hyperlark (Earley)	66.1	69.5
parsimonious (PEG)	201	127
lark (Earley)	1056	1568

These are hyperlark’s default configuration — opt-in switches (fast_scan) widen the gap further on scan-heavy inputs. Reproduce with bindings/python/bench/bench_cli.py, which also checks every library against hyperlark’s result and reports any that disagrees (lark 1.3.1, CPython 3.14.4).

Building the parser

Construction is faster on every grammar, by 1.7× to 5.6×. The widest margin is on python, much the largest grammar here, where table construction dominates — but size alone does not order the rest, and the 85-byte escaped grammar gains more than either mid-size one:

Grammar (LALR)	hyperlark	lark	ratio
JSON	2.74 ms	4.66 ms	1.7×
calc	2.02 ms	4.18 ms	2.1×
escaped-string	0.72 ms	2.42 ms	3.4×
Python (python.lark)	45.5 ms	255 ms	5.6×

From the same sweep as the parse figures above (_results/python.json), so these are one run on one machine — trust the shape rather than the digits. Construction matters most for short-lived processes, where lark pays for table construction on every start.

Addendum: Earley against lark’s Earley

Both engines above are compared against lark’s LALR, which is the conservative reading. Engine for engine, against the Earley that lark runs by default — with parsimonious between them as a yardstick, since a general PEG library is the kind of thing people reach for when they want this much generality:

JSON → value · the general engines (134 KB)

hyperlark (Earley) 66.1 ms

parsimonious (PEG) 201 ms

lark (Earley) 1056 ms

calc → number · the general engines (85 KB)

hyperlark (Earley) 69.5 ms

parsimonious (PEG) 127 ms

lark (Earley) 1568 ms

16.0× and 22.5× against lark's Earley; 1.8–3.0× against parsimonious. Earley is the general engine on both sides, so this is the like-for-like default comparison — but LALR is the engine most users should reach for.

Rust

The core, called directly. Its peers split three ways: code generators (nom is hand-written combinators, lalrpop and pest generate a parser at build time), another runtime engine (tree-sitter), and hyperlark’s own two engines. hyperlark builds its tables at runtime, so grammars stay loadable and editable with no codegen step — that flexibility is the trade for the constant factor against the code generators.

JSON → value (Rust, 134 KB)

nom 0.77 ms

lalrpop + logos 1.18 ms

lalrpop (builtin lexer) 1.64 ms

pest 1.85 ms

hyperlark (LALR) 2.66 ms

tree-sitter 10.2 ms

chumsky 11.5 ms

hyperlark (Earley) 21.9 ms

hyperlark folds during the parse, building no tree — the same shape as nom, chumsky and lalrpop (pest builds a CST and walks it). Building the tree first and folding that costs 2.63 ms, which is the fair figure against tree-sitter (it builds a CST); either way hyperlark leads the other runtime engine ~3.9×. It trails the code generators, which is the cost of building tables at runtime.

calc → number (Rust, 85 KB)

nom 0.41 ms

lalrpop + logos 0.86 ms

hyperlark (LALR) 2.39 ms

lalrpop (builtin lexer) 4.78 ms

hyperlark (Earley) 28.1 ms

Folding during the parse, as lalrpop does in its reduce actions; parsing to a tree and folding that is 3 ms. Either way hyperlark beats lalrpop's own built-in lexer — lalrpop only pulls ahead when paired with logos.

See Alternatives → Rust for what each library is and when to prefer it.

WASM

The wasm binding, which backs both the JavaScript and TypeScript surfaces. This is the one place a hand-tuned native-JS parser can lead: hyperlark pays the wasm tier tax on the parse itself, plus the cost of building a JS value per node. Same result, honest overhead — and it is the tier and the value building, not a crossing per callback: reductions are batched and drained once per chunk.

JSON → value (WASM, 134 KB)

JSON.parse 0.93 ms

chevrotain 4 ms

hyperlark (LALR) 5.28 ms

peggy 5.99 ms

hyperlark transforms during the parse, building no JS tree — the same shape as chevrotain and peggy. Handing back a JS tree and walking it costs 6.18 ms. hyperlark (Earley) is 58.4 ms, off the chart to keep the rest readable; JSON.parse is a native C++ special case, not a parser generator.

calc → number (WASM, 85 KB)

chevrotain 4.6 ms

peggy 5.11 ms

hyperlark (LALR) 5.3 ms

Building a JS tree and walking it instead costs 7.01 ms. The two Earley engines (66.8 and 88.8 ms) are off the scale of this chart and have their own comparison below.

The corpus above is structure-heavy — many small nodes, where hyperlark pays the wasm tier tax on the parse plus the cost of building a JS value per node. On scan-heavy input — few nodes, long tokens (large string or number fields, shallow nesting), where the lexer does most of the work — the native Rust scanner pulls ahead:

scan-heavy JSON (long strings) → value at 1 MB

JSON.parse 0.26 ms

hyperlark 2.69 ms

chevrotain 3.11 ms

~430 long strings instead of many small objects — peggy trails at 18.5 ms. A separate corpus tier from the charts above, so read it as its own comparison. From _results/wasm_comparators_scan.json; reproduce with BENCH_SIZE=scan. The lead over chevrotain is narrow enough to move between runs — read the two bars as close, not as a fixed factor.

Why the spread depends on warmup and shape: chevrotain’s JS JIT has to warm up; wasm is compiled at load. Cold and one-shot workloads flatter wasm; warm, server-style workloads flatter chevrotain. Every number on this page is warm (best-of-N minimum), so the charts are the case that flatters chevrotain. Reproduce with node bench/bench_comparators.mjs in bindings/wasm/, after npm install in bindings/wasm/bench/ — the comparators live in their own manifest so the shipped package stays dependency-free.

Addendum: Earley against nearley

nearley is the JS Earley parser, so it is hyperlark’s like-for-like opponent on the general engine — the same pairing as lark’s Earley in the Python tab.

calc → number · Earley only (85 KB)

hyperlark (dynamic) 66.8 ms

nearley 68.4 ms

hyperlark (dynamic_complete) 88.8 ms

Read the `dynamic_complete` bar against nearley — not the `dynamic` one, whichever order they happen to chart in. nearley is scannerless, so the matched comparison is hyperlark's dynamic_complete lexer, which likewise considers every split — and there nearley leads by 1.3×. hyperlark's default `dynamic` lexer takes the longest match at each position, which is cheaper and less general; benching only that would hand hyperlark a tokenisation nearley never gets.

nearley wins the like-for-like. Worth stating plainly rather than charting the flattering configuration: on equal lexical generality it is 1.3× ahead. Delivery is not the excuse. The harness measures both shapes: on calc the no-tree path is 5.3 ms and handing back a JS tree costs 7.01 ms, so tree delivery is 1.71 ms against an Earley figure of 66.8 ms. The cost is the engine and the dynamic lexer.

There is no JSON comparison here: the bench registers no nearley JSON grammar, so the pair has only ever been measured on calc.

C

The C ABI over the same core, against the classic C parser generators and the other runtime engine. C is LALR only — it does not expose Earley. Like bison and lemon, it folds inline during the parse (lark_parse_fold) and builds no tree, so all three are doing the same shape of work.

JSON → digest (C, 134 KB)

lemon 0.55 ms

flex + bison 0.96 ms

hyperlark (LALR) 2.11 ms

tree-sitter 9.83 ms

All four compute the same digest. bison and lemon generate C at build time, which is the gap; hyperlark builds its tables at runtime and still leads tree-sitter — the other runtime engine, and the only one here that builds a tree (a CST) — by ~4.7×.

Run it on your machine

Parse a corpus on your own hardware — run it in your browser. Treat those numbers as “how it feels here,” not an authoritative leaderboard — browsers coarsen timers and JIT warmup varies, so the controlled numbers above remain the reference.