This page presents detailed transformation timing data collected across multiple XSLT processors and workload configurations. The numbers here are meant to inform architectural decisions, not to declare winners. Every result carries caveats, and understanding those caveats is at least as important as reading the numbers themselves. For the broader context on benchmark methodology, see the benchmarks overview. The Gregor XSLT page explains the compiled transformation approach that produced several of the data points below.

Benchmark Framing

These benchmarks measure the time required to apply an XSLT stylesheet to an XML input document and produce output. They do not measure I/O time, schema validation, or post-processing. The purpose is to isolate transformation engine performance.

Each test configuration specifies:

  • The XSLT processor and version
  • The JDK version (for JVM-based processors)
  • The stylesheet complexity category
  • The input document size category
  • The number of iterations after warmup
  • The reporting metric (median, P95, P99)

All tests were run on dedicated hardware to minimize variance from shared resource contention. The specific hardware configuration is noted in the methodology section below.

Methodology

Hardware: Dedicated test server, 8-core CPU, 32 GB RAM, SSD storage. No other workloads during benchmark execution.

JDK: OpenJDK 17.0.9 for all JVM-based processors.

Warmup: 50 iterations discarded before measurement begins.

Measurement: 200 iterations recorded. Median, P95, and P99 reported.

Stylesheet categories:

  • Simple: Identity transform with minor element filtering. 5 template rules.
  • Moderate: Document restructuring with conditional output, namespace handling, and sorting. 20 template rules.
  • Complex: Multi-stage transformation with recursive processing, complex XPath predicates, grouping, and output formatting. 60+ template rules.

Input categories:

  • Small: 2-5 KB. Flat structure, minimal nesting.
  • Medium: 20-80 KB. Moderate nesting, mixed content.
  • Large: 500 KB-2 MB. Deep nesting, extensive namespace usage.

Results: Saxon HE 12

Workload Input Size Median (ms) P95 (ms) P99 (ms)
Simple Small 2.1 3.4 5.2
Simple Medium 8.3 12.1 15.8
Simple Large 142 168 195
Moderate Small 4.8 7.2 9.1
Moderate Medium 28 35 42
Moderate Large 310 385 420
Complex Small 12 18 24
Complex Medium 85 110 135
Complex Large 890 1050 1180

Saxon HE 12 handles most workloads comfortably. The complex/large combination is where you start to see times that might matter for interactive applications. For batch processing, even the worst case here is under 1.2 seconds, which is acceptable for most throughput requirements.

Results: Xalan-J (Interpreted)

Workload Input Size Median (ms) P95 (ms) P99 (ms)
Simple Small 3.8 5.5 7.1
Simple Medium 15 21 28
Simple Large 245 310 355
Moderate Small 9.2 13 16
Moderate Medium 52 68 82
Moderate Large 580 690 760
Complex Small 24 35 42
Complex Medium 165 210 248
Complex Large 1650 1920 2100

Xalan-J in interpreted mode is consistently slower than Saxon HE, roughly 1.5x to 2x across most configurations. The gap widens on complex stylesheets, which is expected since Saxon’s optimizer handles complex template matching more efficiently.

Results: XSLTC (Compiled)

Workload Input Size Median (ms) P95 (ms) P99 (ms)
Simple Small 0.9 1.4 2.0
Simple Medium 4.1 6.2 8.5
Simple Large 68 85 98
Moderate Small 2.2 3.5 4.8
Moderate Medium 14 19 24
Moderate Large 155 190 220
Complex Small 5.5 8.0 10
Complex Medium 38 50 62
Complex Large 420 510 580

XSLTC compiled transforms show the expected advantage over interpreted execution. The 2x to 4x improvement is consistent. The compilation time itself (not shown here) ranges from 200ms for simple stylesheets to 3 seconds for complex ones, which means the compilation cost pays for itself after 5 to 15 executions depending on the workload.

Results: Browser XSLTProcessor

Workload Input Size Median (ms) P95 (ms) P99 (ms)
Simple Small 1.2 2.0 3.1
Simple Medium 12 18 25
Simple Large 340 450 520
Moderate Small 5.5 8.0 11
Moderate Medium 34 48 58
Moderate Large 820 960 1100

Browser XSLTProcessor results are from Chrome 120. Other browsers show similar patterns with different absolute numbers. Firefox tends to be slightly faster on moderate workloads. Safari shows higher variance. Complex stylesheets are omitted because browser XSLT 1.0 support does not cover all the features used in the complex benchmark stylesheet.

Interpretation Warning Browser XSLTProcessor timing is highly variable due to garbage collection and tab resource sharing. The numbers above are from isolated test pages with no other active content. Real-world performance in a complex web application will be worse.

Common Mistakes When Comparing These Results

Comparing raw medians across categories. A 28ms result for XSLTC complex/medium is not comparable to a 28ms result for Saxon HE moderate/medium. The stylesheets are different.

Extrapolating linearly from input size. Transformation time does not scale linearly with document size for complex stylesheets. XPath predicate evaluation can introduce non-linear behavior depending on tree structure.

Ignoring P95 and P99 values. For latency-sensitive applications, the tail matters. A median of 85ms with a P99 of 135ms means 1% of your transforms take 60% longer than the median. Capacity planning should use P95 or P99, not median.

Assuming these numbers transfer to your workload. Your stylesheets and documents are different from the benchmarks. Use these results for orientation and then benchmark your own workloads.

For a discussion of the compiled transform approach that produces the XSLTC results, see the XSLTC Story. For information on the Gregor tool, which extends compiled transformation with additional optimization and debugging features, see the Gregor XSLT page. The XSLT debugging workflow guide covers how to isolate performance issues in your own stylesheets.

Related Reading