benchmark #

fuz_code runs one hand-written single-pass lexer per language without regular expressions, emitting a flat token event stream that renders to HTML in one forward pass. There is no grammar interpreter and no backtracking, so highlighting cost stays linear in the length of the input, including partial or malformed source.

It is optimized for runtime highlighting, including streaming use cases. Shiki targets build-time use and runs the Oniguruma regexp engine that TextMate grammars require, trading runtime speed for grammar and theme coverage. fuz_code trades that coverage for a small, fast runtime path — it also provides tools for pre-compilation, and you can bring your own lexers for languages it doesn't support.

The cross-implementation benchmark measures fuz_code against Prism and Shiki (both the JavaScript and Oniguruma engines). For end-to-end stylize — lexing plus HTML generation, the realistic runtime path — fuz_code runs roughly an order of magnitude faster than Prism and about two orders of magnitude faster than Shiki:

Representative stylize results on larger inputs from one machine; absolute numbers vary by hardware. See the committed comparison results for the full matrix across engines and sizes, plus tokenize-only rows that compare the raw lexers without HTML generation.

The in-browser benchmark measures real DOM rendering rather than pure compute. It times fuz_code's two renderers — the standard HTML path (Code) and the experimental CSS Custom Highlight API path (CodeHighlight, ranges) — across every supported language, reporting mean, median, percentiles, coefficient of variation, and throughput, with system-stability gating between samples.

Set the iteration count, warmup runs, cooldown, and content multiplier, then run it on your own hardware. For the steadiest numbers, launch Chromium with garbage collection exposed (chromium --js-flags="--expose-gc") so the harness can settle the heap between samples.

A sample run of work time — stylize plus DOM commit — per language for each renderer. The default Code path builds a .token_* span per token; the experimental CodeHighlight path skips that DOM, so it commits less:

Lower is better. The benchmark uses complex samples at the tool's default size, so this is illustrative, not representative of most inputs. The live tool also reports paint-settle time, percentiles, and throughput.

The command-line benchmarks run from a checkout of the repo:

• npm run benchmark — the internal suite, timing every sample at normal and 100× sizes against a local baseline for regression detection.
• npm run benchmark:vs — the cross-implementation shootout against Prism and Shiki that produces the comparison results above.

The internal suite includes a pathological group of adversarial inputs (deeply nested and degenerate source) that pins the lexer's worst-case behavior to linear time; the same generators back the linearity tests. The engine keeps no resumable state, so it re-lexes the whole document on every change rather than tokenizing incrementally — whole-document lexing is already sub-frame at these speeds.

• No regular expressions — char-code scanning, native indexOf, keyword maps.
• One single-pass lexer per language emitting a flat Int32Array event stream, rendered to HTML in a single forward pass.
• Linear-time by construction — every scan loop advances, so there is no catastrophic backtracking on adversarial input.
• No runtime dependencies — nothing heavier than the lexers ships to the browser.

The same entry points power all of it: syntax_styler_global and the SyntaxStyler class expose lex (the flat event stream) and stylize (HTML). See the usage for the API and the samples for output in every language.