benchmark #

fuz_code is optimized for runtime syntax styling. This page compares it with Prism and Shiki, measures its two renderers in the browser, and lists the benchmarks that run from a checkout.

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. For static content, the svelte_preprocess_fuz_code preprocessor renders at build time. Languages it lacks can be added by writing a lexer.

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), 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 the sample languages, 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. Each language's ratios are relative to its highlighted row, and a negative ratio means that many times slower; hover the other row to compare against it. Ratios come from the rounded times shown, and this run does not include Rust. 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 — compares against Prism and Shiki and produces the results above.

The internal suite includes a pathological group of adversarial inputs (deeply nested and degenerate source) that tracks the lexer's worst-case cost; the same generators back the linearity tests.

• 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.
• No grammar interpreter and no regex backtracking; delimiter scans are amortized linear. A test suite checks that lexing time stays near-linear on adversarial inputs.
• No dependencies in the lexers or styler — they import nothing outside the package.

The engine keeps no resumable state, so it re-lexes the whole document on every change rather than tokenizing incrementally. In the committed results the largest inputs, up to a few hundred kilobytes of source, take under about ten milliseconds.

See usage for the API and samples for output in every language.