benchmarks #

tsv is a Rust toolchain for parsing and formatting TypeScript/JS, CSS, and Svelte (source code). Its formatter closely follows Prettier and borrows its architectural patterns, and we're grateful for the hard work of Prettier's contributors. After correctness, tsv prioritizes performance and efficiency: this page measures its speed and size on real-world code, and the conformance page compares parser coverage on edge-case test suites.

This page compares tsv to Prettier and the JS parsers it can replace (Svelte's and acorn-typescript), and to Oxc and Biome, similar tools with more features, configurable styles, and wider language support. It also measures rsvelte, yuku-parser, swc, dprint, Malva, markup_fmt, and PostCSS; Language support lays out what each parses and formats.

tsv formats its three languages faster than Oxc and Biome in every in-process pairing here, and its CLI outpaces theirs using less memory in every shared scenario. Its artifacts are smaller than theirs too, except against oxc-parser's native build, since tsv publishes no native parse-only build yet.

Except in the CLI section, every timing here is in-process and one file at a time, isolating engine speed from multi-core parallelism. The corpus is 7,686 files of real-world code, the author's own plus framework source, third-party libraries, and widely benchmarked TypeScript (see Corpus), timed under Node v24.

• Formatting TypeScript, tsv is ~2.2x faster than Oxfmt (native-vs-native), ~37x faster than Prettier (native Rust vs Prettier's JS; ~26x as wasm), and ~7.7x faster than Biome (wasm-vs-wasm).
• Formatting Svelte, tsv is ~85x faster than Prettier (~58x as wasm) and ~10x faster than Biome (wasm-vs-wasm), and rsvelte currently has no in-process API.
• Formatting CSS, tsv is ~3.7x faster than Oxfmt (native-vs-native), ~114x faster than Prettier (~80x as wasm), and ~12x faster than Biome (wasm-vs-wasm).
• Parsing TypeScript to its default span-only AST (offsets only, like Oxc's), tsv is natively ~1.5x faster than oxc-parser (see Parse speed) and ~2.4x slower than yuku-parser (~3.4x as wasm). With {locations: true}, which adds acorn's per-node line/column loc, it is ~1.2x faster than acorn-typescript, the parser it can replace, and still ahead of Oxc and swc, whose ASTs carry none.
• Parsing Svelte with {locations: true}, whose loc is a superset of Svelte's own, tsv is ~2.0x faster than svelte/compiler (JS) and ~3.0x faster than rsvelte (native-vs-native); its default span-only AST is ~2.6x faster than svelte/compiler.
• Parsing CSS runs the other way, largely because Svelte has a lower fidelity CSS AST which tsv parses to more spec-faithful granularity: Svelte's own parseCss is ~1.9x faster than tsv's default parse, and PostCSS ~1.7x faster (see Parse speed). Under Bun it flips: tsv's default parse leads parseCss by ~1.2x, with parseCss ~1.8x slower there than under Node.
• End to end as a CLI, tsv formats the JSX-free subset of a real TypeScript repo ~1.5x faster than Oxfmt and ~3.9x faster than Biome (~2.6x and ~6.6x as the bare binary, without Node in front), using less memory than either. These are wall-clock ratios, so they include each tool's multi-file parallelism (see the CLI section).
• On a third-party Svelte corpus, tsv's CLI, again through its Node bin, is ~2.9x faster than rsvelte-fmt, another Rust Svelte formatter.

Support matrix for Parsers and Formatters (bold is timed on this page, faded is supported but not timed):

¹ via prettier-plugin-svelte; ² with its jsx option; ³ via the Prettier it bundles, opt-in; ⁴ experimental, behind a flag; ⁵ with Oxc's formatters; ⁶ with dprint's TypeScript and Malva plugins; ⁷ via a separate syntax package.

Each chart's ratios are relative to its highlighted row, and a negative ratio means that many times worse. Hover another row to compare against it instead.

The parsers here don't return the same output, so each ratio compares different amounts of work. They differ in how much position data each node carries (offsets only, or loc too), in how finely they break down CSS (parseCss and PostCSS keep more of it coarse than tsv does), and in what they collect beyond the tree (Oxc also gathers comments and module records). Each tool is compared against tsv's closest output, and the notes cover what still differs.

tsv and oxc-parser, in its default mode, share a mechanism: both serialize the AST to JSON in Rust and hand it to the JS engine's JSON.parse, native and wasm alike. tsv is timed three ways:

• tsv / tsv-wasm is what the parsers return by default: a span-only AST (start/end offsets, no loc) of Oxc's kind. It is the closest comparison with oxc-parser but not an equal one: Oxc's AST also writes out default-valued fields tsv omits (optional: false, decorators: [], typeAnnotation: null), about a third more bytes, and its parse also collects comments and module records. Oxc also has an experimental raw-transfer mode, untimed here, that skips the JSON and may well beat tsv natively.
• +locations passes {locations: true}: the same parse with a loc (line/column) object on every node, rebuilt in JS from the offsets. That is acorn's shape on TypeScript, and on Svelte and CSS a superset of what their reference parsers carry. On the TypeScript corpus it takes ~1.2x the time of the default.
• internal builds tsv's AST in Rust and stops: no serialization, nothing materialized in JS. These entries show raw engine speed. Their gap to the default entries is what serializing and handing off costs tsv, not a cross-tool comparison.

yuku-parser, a JS/TS parser written in Zig, emits the same span-only AST as Oxc, so it too compares against tsv's default entries. It hands JS a compact binary buffer that decodes into objects when its program is read, so the bench reads it to time the same fully materialized result. swc's AST (a Module root with span offsets) matches neither of tsv's outputs.

The numbers above time tsv's engine in-process, one file at a time. This section times the whole CLI end to end, on real code, as you'd experience it from the command line: process spawn, file discovery, I/O, and each tool's default multi-file parallelism, plus peak memory. It comes from a fork of Oxc's own bench-formatter that adds tsv. Upstream's other scenarios aren't shown: their corpora include JSX, which tsv doesn't parse, and two also format a repo's other languages and embedded code, one sorting imports and Tailwind classes too.

As in the charts above, each table's ratios are relative to its highlighted row: tsv via Node dispatcher where tsv faces other tools, and the bare tsv binary in the tsv-only table.

This section ran on October 18, 2026, from its harness at 52a8def, on the same machine and Node as the in-process runs (12 threads). The versions of the tools both sections time are listed under Benchmarking details; its native tsv rows run the @fuzdev/tsv-linux-x64-gnu binary, and its wasm row @fuzdev/tsv-wasm 0.7.0.

The size of each tool's artifact, split by where it runs and grouped by what it does. Bars and ratios are raw bytes; the gz beside each estimates the download. tsv-wasm, tsv (napi), and tsv (ffi) are tsv's full builds: parser and formatter for Svelte, TypeScript/JS, and CSS in one artifact. The format-only and parse-only builds are subsets of them.

The same harness runs under three JS runtimes: Node, Deno, and Bun. The in-process charts above are the Node run, chosen as the default N-API host, not for speed. The native entry differs by runtime: Node and Bun load tsv's N-API addon; Deno loads its C-ABI library (the (ffi) build), which shares the addon's code but crosses a different binding boundary and is built differently. So a per-runtime delta on the same row comes from the JS engine, the host's N-API implementation, or that binding and build, not from tsv's algorithms.

Times are per sweep: one full pass over the group's timed file set, as in the charts above. Ratios are relative to node, negative when slower. The other tools' native rows are their npm N-API addons under all three runtimes.

A ≈ marks a delta inside the two measurements' combined noise: read it as parity. The check has two limits. Each side's noise is the spread of a row's few passes, each a fresh process, which is a thin estimate, so an unmarked delta near it isn't necessarily an effect. And it can't see variance between whole runs.

• node 24.14.1
• deno 2.9.7
• bun 1.4.2

Each row is the mean time per sweep, a pass over its group's timed file set. Within a group every tool is timed on the same files — the intersection of what every timed tool accepted, so a file one rejects drops out for everyone. The count above each chart is that intersection, and a chart that runs short of the corpus total says beneath it what was left out and which rows failed it.

These are warm numbers: every row runs warmup sweeps before it is timed, so a cold one-shot call pays more. Each native or wasm call also pays a string encode across the binding boundary, and a decode wherever it hands back text or JSON, which the JS tools skip.

Each row is timed in 3 passes, and each pass runs until it has both a few seconds of sweeps and at least 8 sweeps, so the slow rows stop at that floor in every pass. After outlier cleaning, rows keep from 19 to 4,155 timings across their passes. A steady reading over a few dozen sweeps is thinner evidence than one over hundreds, so the harness's check for unstable rows proves less for the slow rows, those that ran fewer than twice the floor's sweeps. Prettier, every format chart's default anchor, is among them in each format group:

• Format Svelte: prettier, oxfmt, biome-wasm
• Format TypeScript/JS: every row
• Format CSS: prettier
• Parse Svelte: svelte/compiler, tsv-wasm, tsv+locations, tsv-wasm+locations, rsvelte-parse, rsvelte-parse-skip-expr-loc
• Parse TypeScript/JS: acorn-typescript, tsv, tsv-wasm, tsv+locations, tsv-wasm+locations, oxc-parser, oxc-parser-wasm, yuku-parser, yuku-parser-wasm, swc

Every pass of every row runs in a fresh process that loads that row's tool and nothing else, so no tool's code, garbage, or warmed-up state is shared with the next. Each pass takes a group's rows in a different order (forward, reversed, then rotated), so no row always runs right after the same one, and a row's number is the average of its passes. What no process boundary removes is the machine: nothing pins the process to a core or holds the laptop CPU's clock steady. Two fresh processes of the same row sat 1% apart at the median and 3% at the 95th percentile in this run, so a ratio inside that isn't a difference the run measured. A row whose passes sat 5% or more apart is flagged as unstable, and no row's timings shift more than 3% from the first half of a pass to its second.

One asymmetry isn't isolated. Oxfmt's programmatic format is async-only, so each call's timing includes an N-API task dispatch and a promise resolution that tsv's sync call doesn't pay. (Prettier's is async-only too, without the N-API hop.) Oxfmt's native work may also run off the JS thread: still one file at a time, since each call is awaited before the next, but not strictly one thread.

Every in-process timing on this page comes from 7,686 .svelte, .ts/.js, and .css files of real-world code, vendored in the fuzdev/corpora@976ba90 snapshot so one clone reproduces it. They're the author's libraries, apps, and sites (the fuz.dev ecosystem plus personal SvelteKit projects), and upstream framework source (Svelte, SvelteKit, and the svelte.dev site), community Svelte libraries and tooling (Flowbite Svelte's components, LayerChart, Layer Cake, Svelte UX, svelte-maplibre, and Svelte's language tools), and TypeScript other formatter benchmarks compare on (TypeScript's own parser, Storybook, and Continue). By bytes, code the author didn't write is ~57% of the Svelte, ~56% of the TypeScript/JS, and ~47% of the CSS.

• Test files count as real code and stay in. Fixture files (formatter test suites, and fixture subtrees inside the measured repos) are out: deliberately tricky edge cases measure conformance, not typical throughput, and the conformance page covers them.
• Standalone CSS files are rare in this ecosystem, so the CSS set adds the <style> blocks of the corpus's Svelte components, concatenated per corpus collection — 25 of its 73 entries. Even so, CSS is the weakest sample, with just 48 standalone files.
• Read every ratio here as "on this corpus", not as a universal figure.

tsv's numbers here are from builds without profile-guided optimization (PGO). PGO would make tsv faster but its binaries larger, and that size tradeoff has it on hold.