yuku-tsrx

Benchmarks

There is one benchmark. It compares yuku-tsrx against @tsrx/core, the pure-JavaScript parser Markless uses today, on the same corpus, on one machine, on one day.

Every number on this page is read out of benchmarks/m6-baseline.json. That file is committed, so you can check any of them.

The numbers#

Measure yuku-tsrx @tsrx/core Ratio
Median ns per parse 29,666.2 103,075.4 0.2878
p95 ns per parse 30,307.0 106,420.8
Median parses per second 33,708 9,702
Median peak resident memory 264,740,864 bytes 309,960,704 bytes 0.8541

Read as a sentence: median 29.7 microseconds per parse for yuku-tsrx against 103.1 for @tsrx/core, a ratio of 0.288, and peak resident memory 0.85 times @tsrx/core's. The same four numbers the home page prints, from this table: 3.47 times faster on the median parse, 33,708 parses per second against 9,702, 32.3 MB/s of source against 9.3 MB/s, and 15% less peak memory. MB here means 1,000,000 bytes.

The report's valid field is true, which is the harness's own statement that the run met its noise conditions.

What was measured#
Corpus 224 files, 214,751 bytes total
Iterations 25 per sample
Samples 20, after 5 warmups
Isolation one fresh child process per scenario, variant, and sample; serial seeded order; no forced garbage collection
Conditioning one untimed pass over the corpus before the timed parse loop
Timed region the parse loop only
Peak memory whole-child maximum resident set size
Parse options collect: false, loose: false

Run order alternates between the two parsers across samples, so neither one consistently goes first.

Provenance#
Node v24.15.0
pnpm 10.33.2
Zig 0.16.0
Platform darwin arm64
CPU Apple M5 Pro, 18 logical cores
Memory 51,539,607,552 bytes
Locale C

The report also records the commit of every repository involved, the SHA-256 of the corpus and its manifest, the SHA-256 of each file in the npm package, and the SHA-256 of the native addon, so a rerun can be checked against exactly the inputs this one used.

Measure in this tab#

The numbers above were measured once, on one machine. This figure measures a different thing, in a different place: the WebAssembly build of the same parser, running in your browser, on one small sample.

This runs the WebAssembly build of yuku-tsrx (ReleaseSmall) on one small sample in your browser. What it times is parse(), which includes decoding the result into JavaScript objects, and it times batches of them because a browser clock is deliberately too coarse to resolve a single parse. The report above measured the native Node addon on a 224-file corpus, in a fresh child process per sample, timing the parse loop alone. The two are not comparable: this figure exists so you can watch the parser work, not to reproduce the report.

Sample
Iterations

Nothing has been measured yet. The parser loads when this figure scrolls into view, and runs when you press Run.

the parser runs in your browser; with JavaScript off this figure measures nothing and says so

What this is not#

One benchmark, on one corpus, on one machine, on one day. Treat it as one measurement, not a general claim.

  • It measures parse time and peak resident memory. Nothing else.
  • The corpus is one project's files, not a representative sample of TSRX in general. A corpus with different shape, longer files, deeper markup, more TypeScript types, would give a different ratio.
  • It ran on an Apple M5 Pro. Your hardware will differ, and the two parsers do not have to differ by the same factor on it.
  • Nothing here was rerun to get a better number, and nothing here is a release gate. There is no continuous performance suite in this repository.

The result that mattered more than the ratio was the drop-in check that ran alongside it: on 2026-08-17, against the head of PR #164, Markless's node test suite (229 files, 1832 tests) passed with yuku-tsrx swapped in for @tsrx/core and no test edits, and its typescript-plugin completion matrix was 47/47. A parser that is fast and wrong is not useful.