Benchmarks: 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, measured with a reproducible benchmark: 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.

Contents

• Method
• Speed-up
• Time per scenario
• Peak memory
• Scenarios
• Notes and caveats

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.