GLRMask Isaac Breen
Benchmarks

Published benchmark snapshot

Fast masks are the point. Compilation is the bill.

These are the measurements published with the current GLRMask architecture article. They are useful for understanding the intended trade: very low mask-and-commit latency after a substantially heavier build step.

JSON · median TBM

4.06 µs

10,263-schema paired publication run.

JavaScript · median TBM

40.9 µs

31 tuned fixtures, 4,099 token steps.

JSON Schema

The paired JSON Schema Bench run covered 10,263 schemas and just over three million timed token steps per framework. TBM is per-step mask-and-commit time.

systemmedianmeanp99p99.9max
GLRMask4.06 µs4.52 µs12.8 µs20.7 µs144 µs
llguidance14.7 µs27.1 µs259 µs964 µs7.80 ms

That table is specifically about the repeated runtime. Time to the first mask, including compilation, goes strongly the other way.

JavaScript

JavaScript leaves more lexer/parser work on an online decoder. On the 31-fixture tuned corpus, GLRMask's runtime remains in the tens of microseconds while the comparison system is in the millisecond range.

systemmedianmeanp99p99.9max
GLRMask40.9 µs50.4 µs192 µs306 µs497 µs
llguidance1.05 ms1.17 ms3.28 ms3.83 ms4.13 ms

A smaller direct grammar-shape experiment also gave both systems the same generic js.ebnf. GLRMask's median moved from 50.6 µs to 127 µs; llguidance's moved from 1.60 ms to 21.6 ms. That comparison is about sensitivity to grammar representation, not just absolute throughput.

Compilation

Compilation is deliberately not hidden. On the published JSON run, GLRMask's time to first mask measured 23.8 ms median, 780 ms p99, and 5.11 s maximum; llguidance started much faster. The JavaScript grammars in that publication were more extreme: GLRMask compilation was on the order of tens of seconds on the M1 Pro used for those measurements.

This is the design trade

GLRMask spends more time once so that later token steps have less grammar/tokenizer/parser structure to discover. The right comparison depends on how often the compiled artifact is reused.

How to interpret the numbers

Use the runtime numbers when the constraint is reusable. They describe the cost that repeats for every generated token and every request that shares the compiled artifact.

Use total startup + runtime when the constraint is one-off. A fresh JSON Schema used for one short request can favor a decoder with tiny startup cost even if its per-token mask is slower.

Aggregate percentiles also hide where individual slow token boundaries appear. The token-by-token investigation shows real JSON and JavaScript inputs with each model token colored by its measured TBM.

Open the token-by-token benchmark article →