RustyXML Benchmarks

Performance comparisons against SweetXml/xmerl.

Test Environment

• Elixir: 1.19.4
• OTP: 28
• Hardware: Apple Silicon M1 Pro (10 cores)
• RustyXML: 0.2.1
• SweetXml: 0.7.5
• NIF memory tracking: enabled

Variance: Throughput numbers vary ±15% between runs on the same hardware depending on thermal state, background load, and GC timing. Speedup ratios (RustyXML vs baseline) are more stable than absolute ips. Streaming memory measurements use :erlang.memory(:total) deltas and can vary ±30%.

Parsing Performance

RustyXML's structural index uses SIMD-accelerated scanning (memchr) and zero-copy spans. Gains increase with document size.

Small Document (14.6 KB, 50 items)

Medium Document (290.6 KB, 1,000 items)

Large Document (2.93 MB, 10,000 items)

XPath Query Performance

All queries run on pre-parsed documents.

XPath on Pre-Parsed Document (290.6 KB, 1,000 items)

Complex XPath Queries (2.93 MB, 10,000 items)

Lazy XPath API (290 KB, 1,000 items)

The lazy API keeps results in Rust memory, building BEAM terms only when accessed:

Recommendation: Use batch accessors (result_texts, result_attrs, result_extract) when accessing multiple items to reduce NIF call overhead.

Memory Comparison

Measurement Methodology

• RustyXML "Total" = NIF peak (instantaneous high-water mark via mimalloc tracking) + BEAM allocations (Benchee GC tracing for parse; :erlang.memory(:total) delta for streaming)
• SweetXml "BEAM" = Total BEAM allocations measured by Benchee's GC tracing, which includes memory that was subsequently garbage-collected — i.e. cumulative allocations, not peak
• Streaming uses :erlang.memory(:total) snapshot deltas, which are noisier than Benchee's per-process GC tracing

These are not identical metrics. The ratios are directionally correct but should not be taken as exact.

Parse Memory

XPath Memory

Streaming Memory

Note: SweetXml's stream_tags retains every parsed element in xmerl's accumulator for the entire parse, so 73 MB reflects genuine SweetXml behavior but is not representative of a properly bounded streaming parser. For a fairer comparison, see the Saxy Comparison where both parsers use bounded memory (~128 KB vs ~124 KB).

Streaming Comparison

Feature Comparison

Streaming Performance (10,000 items, 2.93 MB)

Saxy Comparison

RustyXML also serves as a drop-in Saxy replacement. SAX parsing benchmarks against Saxy 1.6:

SAX Parse Performance

Measured on Apple Silicon M1 Pro. Throughput varies ±15% between runs; speedup ratios are more stable.

SAX Memory

parse_stream memory is comparable: both parsers operate in bounded memory. RustyXML uses zero-copy tokenization and direct BEAM binary encoding to keep the NIF peak at ~67 KB. Streaming memory measurements use :erlang.memory(:total) deltas which are noisier than Benchee's per-process tracing — expect ±30% variance between runs on the same hardware.

Summary

Speed Rankings

Memory Rankings

Recommended API by Use Case

Key Findings

1. Parsing is 8-72x faster than SweetXml — The structural index with SIMD scanning dramatically outperforms xmerl, with gains increasing on larger documents.

2. SAX parsing is ~1.3-1.8x faster than Saxy — with comparable streaming memory. This is the fairest streaming comparison since both parsers are properly bounded.

3. All XPath queries are faster — Full elements (1.48x), text (2.0x), attributes (1.7x), predicates (3.65x), counts (2.8x) vs SweetXml.

4. Lazy XPath is 3-4.4x faster — Keeping node IDs in Rust and accessing on-demand eliminates BEAM term construction overhead.

5. Significantly less memory for parsing — The structural index uses compact spans instead of string copies. Parse memory for 2.93 MB doc: 12.8 MB (NIF peak + BEAM) vs SweetXml's 1,133 MB (BEAM total allocations). Note: these are different metrics — the magnitude of difference is real but the exact ratio is approximate.

6. Stream.take works correctly — Fixes SweetXml issue #97. Bounded memory regardless of file size.

Improvement from v0.1.1 to v0.1.2

The unified structural index brought substantial gains over the prior DOM-based approach:

Running the Benchmarks

# vs SweetXml
FORCE_RUSTYXML_BUILD=1 mix run bench/sweet_bench.exs

# vs Saxy
FORCE_RUSTYXML_BUILD=1 mix run bench/saxy_bench.exs

Enabling Memory Tracking

# In native/rustyxml/Cargo.toml
[features]
default = ["mimalloc", "memory_tracking"]

FORCE_RUSTYXML_BUILD=1 mix compile --force

RustyXML.Native.reset_rust_memory_stats()
doc = RustyXML.parse(xml)
peak = RustyXML.Native.get_rust_memory_peak()
current = RustyXML.Native.get_rust_memory()

Correctness Verification

All benchmarks include correctness verification:

count(//item): RustyXML=1000, SweetXml=1000 - ok
//item[1]/name/text(): RustyXML="Product 1", SweetXml="Product 1" - ok
//item/@id count: RustyXML=1000, SweetXml=1000 - ok

Overall: ALL TESTS PASSED