Benchmarks

How fast each release of @tradik/xslt-processor is, and how the XSLT 3.0 engine @tradik/xslt3 compares, on the same stylesheets and the same machine. Start with All versions: one chart and one table with every version. The sections after it are the detailed runs those numbers come from.

Contents

• All versions: 1.1.3, 1.2.0, 1.3.0 and @tradik/xslt3 side by side
• 1.1.3 vs 1.2.0: the 1.2.0 release run, including CLI, streaming and the standalone binary
• XPath 1.0 vs XPath 3.1: the 1.0 package against @tradik/xslt3
• XSLT 1.0 vs XSLT 3.0 engines: the 1.0 package against @tradik/xslt3 on the same stylesheets, idiomatic 2.0/3.0 rewrites, 3.0-only scenarios, start-up and bundle size

All versions

Against 1.1.3, on the same 9 XSLT 1.0 stylesheets (geometric mean): 1.2.0 1.40× faster · 1.3.0 1.49× faster · xslt3 1.0.0 2.89× faster.

Every version runs the same XSLT 1.0 stylesheets on jsdom. Lower is faster; the fastest version of each row is in bold. 1.2.1 changed no library code, so 1.2.0 stands for both.

Peak memory (maximum resident set size of the process, including Node.js, jsdom and the parsed documents):

The numbers come from two runs on the same machine, Node.js and jsdom: 1.1.3 and 1.2.0 from the 1.1.3 vs 1.2.0 run (30 September 2026), 1.3.0 and @tradik/xslt3 from the XSLT engines run (2 October 2026). The first times stylesheet import and transformation together; for the second the table adds its compile and transform medians. Differences of a few percent between the two runs are noise, not a change.

1.1.3 vs 1.2.0

How much faster and leaner 1.2.0 is than the released 1.1.3 on the same inputs: speed-up per scenario, time per scenario and peak memory, each chart followed by its data table.

1.81× faster on 100 MB text result, string · 1.39× geometric mean over 10 scenarios · 58% less peak memory on 100 MB text result, string (1557 MB to 650 MB) · call-template depth 3,000: runs on 1.2.0, error on 1.1.3.

Method

• Machine: AMD Ryzen 9 7950X 16-Core Processor, 32 logical cores, 31 GB RAM, Linux 6.18.40.1-microsoft-standard-WSL2 (linux)
• Node.js 25.9.0; DOM: jsdom 30.1.1 (library runs and both CLIs), @xmldom/xmldom 0.9.12 (xmldom CLI row)
• Runs: 2 warm-up + 7 measured per version and scenario, each pair in its own process; a run over 120 s counts as a timeout. Scenarios slower than 10 s per run use 1 warm-up + 3 runs
• Recorded 2026-09-30; the whole run took 6.2 minutes

1.2.0 is the working tree; 1.1.3 is extracted from its git tag (git archive v1.1.3) into the system temporary directory and installed with npm ci --ignore-scripts. Every version and scenario runs in its own child process, so the versions never share a heap, a JIT or a module cache. Library scenarios parse the inputs once with jsdom and time new XSLTProcessor() + importStylesheet() + transformToString() (or reading transformToStream() to the end), with a garbage collection before each run. CLI scenarios time the whole xslt in.xml t.xsl -o out.html process, start-up included. Peak memory is the process's maximum resident set size (process.resourceUsage().maxRSS), so it includes Node.js, jsdom and the parsed documents. The inputs are generated deterministically by scripts/benchmark/inputs.mjs; nothing is downloaded.

Reproduce:

npm ci --ignore-scripts && npm run build
npm run bench                       # writes scripts/benchmark/results.json
node scripts/benchmark/charts.mjs   # redraws docs/benchmarks/*.svg and the tables below

npm run bench -- --runs 3 --only catalog,sort runs a subset. The charts and tables on this page are generated from scripts/benchmark/results.json.

Speed-up

Time per scenario

Peak memory

Scenarios

Notes and caveats

• jsdom dominates wall time. Every DOM access of the engine crosses jsdom's wrappers; parsing the inputs is excluded from library runs but not from CLI runs. With XSLT_DOM=xmldom the same CLI transformation is much faster, see the CLI rows.
• Numbers vary by machine. Compare factors, not absolute times, and rerun npm run bench on your own hardware; run-to-run spread is visible in the p95 and min columns.
• What changed in 1.2.0 (see the CHANGELOG):
  • Serialization walks the result tree on an explicit stack and writes bounded chunks that are joined once (task 0024 and the chunked serializer of task 0010): the identity transform, the catalogue and the 100 MB text result are faster, and the 100 MB result needs well under half the peak memory of 1.1.3.
  • transformToStream() (task 0010) serializes on demand, so the consumer never holds the whole result as one string: the streamed 100 MB row peaks lower than the string row of the same version.
  • Templates run from an explicit work stack (task 0005): 3,000 nested templates work, where 1.1.3 stops at about 1,000 to 1,400 levels with Template recursion too deep.
  • Document order is computed once per transformation (DocumentOrderIndex, task 0007) instead of calling compareDocumentPosition for each comparison.
  • The CLI can use @xmldom/xmldom (task 0007), which starts faster and parses faster than jsdom. jsdom stays the default because it expands entities declared in an internal DTD subset and xmldom does not.
  • Sorting nodes in document order no longer reads every attribute's index in its element, and name tests read the document's content type only when it matters. Before that fix Muenchian grouping was the one scenario slower than 1.1.3 (about 0.88×); it is now faster too.
• Most of the large algorithmic fixes (linear template matching, keys, xsl:number, axis::x[n]) already shipped in 1.1.2 and 1.1.3, so both versions here are within a small factor of each other on those scenarios; the gains of 1.2.0 are in serialization, memory, recursion depth and the CLI.

XPath 1.0 vs XPath 3.1

XPath 1.0 of this package (src/, parseXPath() / evaluateXPath()) against XPath 3.1 of @tradik/xslt3 (packages/xslt3, compileXPath() / evaluateXPath()), on the same expressions over the same DOM.

On jsdom, xslt3 is 3.21× faster than the 1.0 package (geometric mean of the time ratio over 11 scenarios; from 0.17× the time on (//item)[1000] to 0.67× on ancestor::* from 1,000 deep nodes) · on xmldom, xslt3 is 2.65× faster than the 1.0 package (geometric mean of the time ratio over 11 scenarios; from 0.18× the time on //item to 0.83× on translate/concat/substring × 20,000).

XPath method

• Machine: AMD Ryzen 9 7950X 16-Core Processor, 32 logical cores, 31 GB RAM, Linux 6.18.40.1-microsoft-standard-WSL2 (linux)
• Node.js 25.9.0; DOM: jsdom 30.1.1, @xmldom/xmldom 0.9.12
• Engines: 1.0 package 1.3.0 (src/index.js), xslt3 1.0.0 (packages/xslt3/src/index.js)
• Runs: 2 warm-up + 7 measured per phase (compiled, then one-shot), each scenario, DOM and engine in its own process; a run over 120 s counts as a timeout. Phases slower than 10 s per run use 1 warm-up + 3 runs
• Recorded 2026-10-02; the whole run took 2.66 minutes

The document is generated by scripts/benchmark/xpathScenarios.mjs: 20,000 item elements (an id, a category, a price from 0.00 to 99.99 and a name; an a child in every second item, a b child in every third, a chain of 12 nested elements in every 20th), about 2.4 MB, parsed once per process with jsdom or @xmldom/xmldom (not timed). Each scenario is measured twice:

• compiled: the expression is compiled once (parseXPath() in the 1.0 package, compileXPath() in xslt3), then each run evaluates it (a new XPathEvaluator and XPathContext per evaluation in the 1.0 package, as evaluateXPath() does; compiled.evaluate(node) in xslt3). Neither engine keeps state between evaluations, so each builds its own document order index;
• one-shot: each run calls evaluateXPath(expression, node), which parses and evaluates.

Scenarios marked × 20,000 or "from 1,000 deep nodes" evaluate the expression once per element in a JavaScript loop, so they also measure the per-call cost. The 1.0 package caps a node-set at 10,000 nodes by default (XPathLimits.MAX_RESULT_SIZE, a guard for untrusted expressions) and evaluateXPath() takes no option for it, so the benchmark raises the exported limit to the XSLT engine's 5,000,000. Peak memory is the process's maximum resident set size, so it includes Node.js, the DOM and the parsed document; one process runs both phases.

Reproduce:

npm ci --ignore-scripts
npm run bench -- --suite xpath                # writes scripts/benchmark/results-xpath.json
node scripts/benchmark/charts.mjs --suite xpath   # redraws docs/benchmarks/xpath-*.svg and the tables below

npm run bench -- --suite xpath --dom jsdom --runs 3 --only sum,union runs a subset. Before measuring, a pre-check evaluates every scenario once per engine and DOM and stops the run when the engines disagree (item count and a hash of every item, nodes by name and id, numbers by value), or when an XPath 3.1-only expression fails; --allow-mismatch measures anyway and records the differences.

Pre-check

Both engines returned the same result (item count and a hash of every item) for every shared scenario on every DOM, and every xslt3-only expression evaluated without an error.

XPath time ratio

XPath time on jsdom

XPath time on xmldom

XPath 3.1-only expressions

What XPath 1.0 cannot express at all, on xslt3 alone.

XPath peak memory

XPath notes

• On jsdom the engines are close; xslt3 is slower on most single expressions. Both spend most of their time walking jsdom's wrappers. A CPU profile of xslt3 shows two costs the 1.0 package avoids: childrenOf() iterates node.childNodes, and in jsdom every indexed childNodes access goes through a Proxy (the 1.0 package walks firstChild / nextSibling for exactly this reason, see src/xpath/axes.js); and //a | //b and //item[last()] number the whole tree, attributes included, for document order on every evaluation (DocumentOrder.index(), 16% of the union's profile). Typed atomic values (each untyped @price cast to xs:double, count() as an xs:integer BigInt) did not show up as a major cost in the profiles of count(//item[@price > 50]) and //item[last()]: the tree walk does.
• xslt3 is faster on per-node loops. Its compiled evaluation of following-sibling::item[1] and ancestor::* costs less per call than a new XPathEvaluator and XPathContext; one-shot it is slower, because parsing an XPath 3.1 expression (a much larger grammar) costs more: translate/concat/substring compiled 20,000 times takes about twice as long as in the 1.0 package. Compile once and reuse the expression.
• On xmldom the 1.0 package's standalone XPath API used to be the outlier. Before 1.3.0 every expression that returned or sorted a large node-set (//item, (//item)[1000], sum(//item/@price), //a | //b) took 7 to 33 s there, because XPathEvaluator sorted with xmldom's compareDocumentPosition, which is written in JavaScript and walks ancestors on every comparison. 1.3.0 numbers the tree once per evaluation unless the DOM's method is native (task 0036): the same expressions now take 60 to 115 ms with the 1.0 package and 13 to 50 ms with xslt3.
• XPath 3.1-only expressions run in the same range as the shared ones. The slowest is distinct-values grouping written as a nested loop (50 categories × 20,000 items, 0.65 s on jsdom, 0.56 s on xmldom), which per-evaluation caching of descendant results (task 0037) brought down from 7.8 s; in XSLT 3.0 xsl:for-each-group or a map built in one pass avoids the nested loop altogether.
• Same answers. Results are compared by count and by a hash of every item; numbers compare by value, so count() (a JS number in 1.0, an xs:integer BigInt in 3.1) and sum() (both IEEE doubles, added in document order) must agree to the last bit, and do.
• Memory is dominated by the DOM: jsdom processes peak at 300 to 370 MB and xmldom processes at 230 to 290 MB with either engine.

XSLT 1.0 vs XSLT 3.0 engines

The XSLT 1.0 engine of this package (src/, XSLTProcessor) against the XSLT 3.0 engine of @tradik/xslt3 (packages/xslt3, compileStylesheet() + transform() + serialize()), in three groups:

1. The same XSLT 1.0 stylesheets as the 1.1.3 vs 1.2.0 suite, run by both engines; they declare version="1.0", so xslt3 runs them in backwards-compatible mode.
2. The same tasks rewritten idiomatically in XSLT 2.0/3.0, run by xslt3: is rewriting a 1.0 stylesheet worth it?
3. XSLT 3.0-only tasks that 1.0 cannot express directly: grouping, regular expressions, iteration with state, JSON in and out, maps, higher-order functions, accumulators, merging.

On jsdom, xslt3 is 2.13× faster than the 1.0 package (geometric mean of the time ratio over 9 scenarios; from 0.21× the time on 100 MB text result to 1.02× on Muenchian grouping, 8,000) · on xmldom, xslt3 is 1.94× faster than the 1.0 package (geometric mean of the time ratio over 9 scenarios; from 0.16× the time on following-sibling::x[1], 8,000 to 1.13× on Muenchian grouping, 8,000) · rewritten in XSLT 2.0/3.0, the same tasks run 1.66× faster on xslt3 than their 1.0 stylesheets (geometric mean over 6 tasks on jsdom; 3.91× faster on Muenchian grouping, 8,000).

XSLT engines method

• Machine: AMD Ryzen 9 7950X 16-Core Processor, 32 logical cores, 31 GB RAM, Linux 6.18.40.1-microsoft-standard-WSL2 (linux)
• Node.js 25.9.0; DOM: jsdom 30.1.1, @xmldom/xmldom 0.9.12
• Engines: 1.0 package 1.3.0 (src/index.js), xslt3 1.0.0 (packages/xslt3/src/index.js)
• Runs: 2 warm-up + 7 measured per phase (compile, then transform), each scenario, DOM and engine in its own process; a run over 120 s counts as a timeout. Phases slower than 10 s per run use 1 warm-up + 3 runs
• Recorded 2026-10-02; the whole run took 8.25 minutes

Inputs are generated deterministically, the 1.0 ones by scripts/benchmark/inputs.mjs (the same bytes as the 1.1.3 vs 1.2.0 suite), the rewrites by xsltRewrites.mjs and the 3.0-only ones by xslt30Inputs.mjs and xsltJson.mjs. Each worker process parses the source and the stylesheet once (not timed) with jsdom or @xmldom/xmldom, installed globally as the xslt CLI does, and measures two phases:

• compile: new XSLTProcessor() + importStylesheet() in the 1.0 package, compileStylesheet() in xslt3;
• transform: one transformation with the compiled stylesheet, including serialization to a string (transformToString() in the 1.0 package; transform() + serialize() with the stylesheet's output parameters in xslt3). The charts and the time tables show this phase.

Peak memory is the process's maximum resident set size, so it includes Node.js, the DOM and the parsed documents; one process runs both phases.

Reproduce:

npm ci --ignore-scripts
node scripts/benchmark/run.mjs --suite xslt        # writes scripts/benchmark/results-xslt.json
node scripts/benchmark/charts.mjs --suite xslt     # redraws docs/benchmarks/xslt-*.svg and the tables below

node scripts/benchmark/run.mjs --suite xslt --dom jsdom --runs 3 --only catalog,catalogRewrite runs a subset (the scenario ids are in xsltScenarios.mjs); --no-startup skips the bundle and import measurements.

XSLT engines pre-check

Before anything is timed, every scenario runs once per engine and DOM and the outputs are compared: both engines on each 1.0 stylesheet, and each rewrite against the 1.0 package's output of the original stylesheet; every 3.0-only stylesheet must run, and xslt3 must write the same output on every DOM. Two serializer defaults are removed before comparing, because they are not results: the line break the 1.0 package writes after the XML declaration (as libxslt does), and the <!DOCTYPE html> that XSLT 3.0 writes for the html output method (HTML5 by default). Anything else stops the run, unless --allow-mismatch records it.

Both engines wrote the same output for every XSLT 1.0 stylesheet on every DOM, every rewrite reproduced the 1.0 package's output of the original stylesheet, every XSLT 3.0-only stylesheet ran without an error, and xslt3 wrote the same output on every DOM.

XSLT 1.0 stylesheets on both engines

Rewritten in XSLT 2.0/3.0

Each task keeps its source document and must produce the same output; only the stylesheet changes:

XSLT 3.0-only scenarios

XSLT engines compile time

Start-up and bundle size

Each package bundled as one minified ES module for browsers, the way the website bundles @tradik/xslt3 for its playground (site/scripts/vendor.mjs), and the time a fresh Node.js process takes to import() it, from source and from that bundle (median of the runs, one process each).

XSLT engines peak memory

SaxonJS

SaxonJS 3, Saxonica's XSLT 3.0 processor for JavaScript, is the reference the milestone in XSLT3.md names. On npm it is saxonjs-he with the xslt3-he compiler (3.0.0-beta2; saxon-js and xslt3 are SaxonJS 2). Its licence (Saxonica's "SaxonJS licence", version 2.0, December 2024, shipped as LICENSE.txt) allows use and redistribution in binary form but says nothing about publishing benchmark results, and the package is a preview beta. This page therefore publishes no SaxonJS numbers, and SaxonJS is not a dependency of this repository. To compare locally, install it outside the repository and point the benchmark at it; its results are written to the system temporary directory, never to results-xslt.json:

npm install --prefix /tmp/saxon saxonjs-he xslt3-he
node scripts/benchmark/run.mjs --suite xslt --saxon-dir /tmp/saxon

Each stylesheet is then compiled to SEF with xslt3-he -export -nogo (timed separately), and SaxonJS.transform() of the SEF is timed on a tree SaxonJS parsed itself; its outputs are compared with xslt3's, ignoring whitespace between tags (SaxonJS indents HTML by default).

XSLT engines notes

• xslt3 runs the 1.0 stylesheets faster than the 1.0 package on both DOMs: 2 to 7 times on sorting, following-sibling::x[1] in a loop, recursion, xsl:number level="any" and the 100 MB text result (which also peaks at 290 MB of memory instead of 660 MB on jsdom). The catalogue, the identity transform and Muenchian grouping are within 15%, because building and serializing the result tree dominates them. xsl:number level="any" was quadratic in xslt3 before release (8,000 nodes took 41 s); it now remembers the last number per instruction and takes 35 ms (task 0038).
• Rewriting pays off where the 1.0 idiom was a workaround.xsl:for-each-group instead of Muenchian keys is almost 4 times faster on the grouping scenario and 1.5 times on the catalogue; on-no-match="shallow-copy" saves 20% (jsdom) to 30% (xmldom) on the identity transform; sort() with a key function costs about the same as two xsl:sort keys.
• JSON: parse-json() reads 5 MB of JSON 10 times faster than json-to-xml() on jsdom and with a quarter of the memory: the XML representation of the JSON is a DOM tree of hundreds of thousands of elements, and the json-to-xml processes peak at 1.4 GB (jsdom) to 2 GB (xmldom), mostly in the DOM library itself.
• Accumulators over a 29,000-element document take 0.7 s on jsdom and 0.5 s on xmldom.
• jsdom or xmldom: both engines usually run 1.5 to 3 times faster on @xmldom/xmldom than on jsdom; the ranking of the engines does not change.
• Compiling a stylesheet takes 0.5 to 2 ms with either engine, so reusing a compiled stylesheet matters only for small transformations.
• Start-up: the xslt3 bundle is 2.5 times the 1.0 package's (117 kB against 47 kB gzip) and takes 2.6 times as long to import from source in Node.js (78 ms against 30 ms); the 1.0 package does not load it unless asked to (see XSLT3.md, "Opt-in bridge").