syntax-highlighter-bench results

MB/s compares across inputs of different sizes, and time per call does not: inputs in one size tier can differ several times over in bytes. A geometric mean covers only the rows where every selected library has a number, and says how many. A disturbed mark is a value whose rounds disagreed, and retried one that was measured again. A ratio marked ≈ is inside the machine's noise floor.

Bundled is the one chunk whose size is reported below, and unbundled imports the same entry with its imports resolved from node_modules. A ratio between small additions is large even when the processes take nearly the same time.

An addition smaller than bare Node's own band, from its 10th to its 90th percentile, is marked in the noise: it can't be told from adding nothing, and has no ratio. In a row with such an addition the others are compared with that band instead of with the best, and marked ≥: at least so many times the band, and so at least so many times the best, which is inside it. Such a row is left out of the mean. A reference library is used only in the rows where its own addition is outside the noise.

The first language is the bundle with that language alone, less the bundle with none. One more language is what it adds to a bundle of every other timed language, always in minified bytes, whatever the Bytes selector says: compressing a whole bundle doesn't separate one part of it. The floor plus each language alone is not a bundle, so it has no ratio: it exceeds the set's measured size when a library shares code between languages, or when one language brings another with it, as HTML brings the script and style languages. The wasm binary and the theme stylesheet are loaded beside the JS, and each has a row of its own.

It is everything the packages ship, every language, theme, and type declaration included, and not what a page loads, which the tables above show. The ratios are to the smallest and are not colored: a library that ships more languages installs more, and installs it once.

A Node process imports the library's bundle of that language alone, the one whose size is reported above, highlights the language's snippet, lets go of the HTML, and collects garbage until the heap settles. Larger inputs leave more, most of all for regexp and wasm engines.

Machine code holds the regular expressions the engine compiled as well as optimized functions, and is the processor's: these figures are x64's. External memory is where a WebAssembly engine keeps its linear memory, counted at the size it has grown to, which it never gives back; the OS backs only the pages it has touched, so resident memory can be lower. The sum of the three is shown first and ranked, so neither a regexp engine nor a wasm engine is compared without what it holds; the Parts filter shows each on its own. A ratio within the heap check's tolerance is marked ≈.

A theme in a stylesheet is held by the page, not the library, so a library that writes its styles inline holds its theme here and one with classes doesn't. The figures are for one Node version; the deterministic metrics docs say which, and what moves them.

The ratios are to the smallest in each row and are not colored, because smaller is not better here: libraries split the same source differently and wrap their HTML differently, so fewer tokens is a coarser split, not a better one, and HTML with inline styles carries its theme where HTML with classes leaves it to a stylesheet. The deterministic metrics docs say what each counts.