Benchmark Results

The results of the benchmarks in bench/: every PEGO backend (closure, recursive and iterative bytecode VMs, Go parsers generated by pego gen) and, where a comparable parser exists, the Go standard library. What the benchmarks measure, the analysis of these results, and the history of the optimizations behind them are in performance.md.

This file is generated: go run ./bench/report runs the benchmarks, measures the generated TypeScript parsers and the sizes of the generated parsers, saves the raw results to bench/results.txt, bench/results-ts.txt and bench/results-size.txt and writes this file from them; go run ./bench/report -in bench/results.txt rewrites it from saved results. Do not edit it by hand: a test checks that it matches the results.

#Run

Measured on 2026-10-29 at commit 13b3d186 with go1.27.1 on Apple M3 Max (darwin/arm64, 16 cores), with a load average of 3.54 3.98 4.39 (1, 5 and 15 minutes) when the run started. Times and memory are per operation, the median of 3 runs. Factors in parentheses are relative to the closure backend (lower is faster), except where a table says otherwise. The generated TypeScript parsers were measured with Node v24.13.0.

#Results

#Parsing Time (Position Unit: Code Points)

#Parsing Time (Position Unit: Bytes)

#Memory per Parse (Position Unit: Code Points)

Bytes allocated / number of allocations.

#Memory per Parse (Position Unit: Bytes)

#Typed Values (ParseAST of pego gen -types)

ParseAST builds the grammar's Go types directly when every value it can return has a Go type of its own ("direct"); otherwise (the values include CST nodes, as in minilang and recovery) it runs Parse and converts the tree ("converted"). CSV builds typed File, Record, and Field values directly. See code generation. The factor is relative to the generated parser's Parse (code points).

#Recognition Only (RecognizeOnly, No Tree)

Memory per recognition (bytes allocated / number of allocations):

#Incremental Parsing (Minilang, One-Character Edit Followed by a Parse)

#Incremental Parsing of a Long Document (CSV, 50,000 Records, One-Character Edit Followed by a Parse)

#Streaming (CSV, 50,000 Rows, 2.17 MB)

#Preparation (Time Until a Grammar Is Ready to Use)

Loading a .pegoc file includes the execution setup performed on the first parse after loading (preparing the VM). A compiled grammar holds the module of one mode and runs on the bytecode backend; each column loads the file of its mode and sets it up with a parse that the mode serves.

Memory (bytes allocated / number of allocations) and file sizes:

#Generated TypeScript (Node v24.13.0)

pego gen -lang ts -types -recognize parsers, run under node --experimental-strip-types (16 cores, V8 13.6.233.17-node.37, commit 13b3d186, measured on 2026-10-29, load average 2.69 3.50 3.90 when the run started). Each figure is the median of 3 runs of bench/ts-parse.mjs, one fresh process per run, after a warm-up of one second: the mean time of a parse of the same input as the Go tables, in code points, with the throughput in parentheses. parse builds the Node tree, parseAST the typed values and recognize builds nothing. The last column is the time of parse relative to the generated Go Parse of the table above (lower is faster).

#Generated Parser Size

Sizes of the parsers in parsers/, generated with the options of parsers/generate.go (commit 13b3d186, go1.27.1). "Go source" is the committed parser.go; "Go binary" is a program that calls the parser's ParseAST, built with -trimpath -ldflags="-s -w", so it includes the PEGO runtime and the parser's types. "TypeScript" is the generated parser.ts, raw and compressed with gzip -9; it imports the embedded runtime, which is the same for every parser and weighs 146 KB (36.9 KB gzipped).

#All Results

Every benchmark of the run, by its name under bench/ (median of the runs; the throughput is in MB/s of input).