RustyCSV Benchmarks

This document presents benchmark results comparing RustyCSV's parsing and encoding performance against pure Elixir (NimbleCSV 1.3.0).

Test Environment

• Elixir: 1.19.4
• OTP: 28
• Hardware: Apple Silicon M1 Pro (10 cores, 16 GB RAM)
• RustyCSV: 0.3.6
• Pure Elixir baseline: NimbleCSV 1.3.0
• Test date: February 2, 2026

Note: All results below were collected on this specific hardware. Absolute throughput numbers will vary on different machines, but relative speedups should be broadly representative.

Strategies Compared

Both batch strategies share a single-pass SIMD structural scanner that finds every unquoted separator and row ending, then create BEAM sub-binary references into the original input. :simd extracts boundaries single-threaded; :parallel uses rayon across multiple threads, then builds sub-binary terms on the main thread.

Throughput Benchmark Results

Simple CSV (334 KB, 10K rows, no quotes)

Quoted CSV (947 KB, 10K rows, all fields quoted with escapes)

Mixed/Realistic CSV (652 KB, 10K rows)

Large CSV (6.82 MB, 100K rows)

Very Large CSV (108 MB, 1.5M rows)

Memory Comparison

RustyCSV allocates on the Rust side (boundary vectors during parsing) while pure Elixir allocates entirely on the BEAM. With the memory_tracking feature enabled, we measure Rust NIF peak allocation alongside Benchee's BEAM-side measurement.

Methodology

We measure two metrics:

1. NIF Peak: Peak allocation on the Rust side during parsing (requires memory_tracking feature)
2. BEAM Allocation: Memory allocated on the BEAM during parsing (what Benchee measures)

RustyCSV's BEAM-side allocation is ~1.6 KB across all strategies — just list/tuple scaffolding. The parsed field data lives as sub-binary references into the original input binary (no per-field copy).

Decode Memory by File Type

Key insight: RustyCSV uses 5-14x less memory than pure Elixir. All batch strategies (including parallel) use boundary-based sub-binaries — just Vec<Vec<(usize, usize)>> boundary indices (16 bytes per field). Parallel has slightly higher NIF peak due to rayon thread-pool overhead.

BEAM Reductions (Scheduler Work)

What this means:

• Low reductions = less scheduler overhead
• NIFs run outside BEAM's reduction counting
• Trade-off: NIFs can't be preempted mid-execution

Streaming Comparison

File: 6.8 MB (100K rows)

File.stream! Input (parse_stream/2)

Result: RustyCSV is 2.2x faster for line-based streaming.

RustyCSV automatically detects File.Stream in line mode and switches to 64KB binary chunk reads, reducing stream iterations from ~100K (one per line) to ~100. The Rust NIF handles arbitrary chunk boundaries internally, so it can operate on raw binary chunks rather than pre-split lines.

Arbitrary Binary Chunks

RustyCSV can also process arbitrary binary chunks directly (useful for network streams, compressed data, etc.). Pure Elixir parse_stream operates on line-delimited input, which is the standard approach when using File.stream!/1.

Real-World Benchmark: Amazon Settlement Reports

This section presents results from parsing Amazon SP-API settlement reports in TSV format.

Test Data

• Data source: Amazon Seller Central settlement reports (TSV format)
• Report sizes: 1KB to 2.6MB (20 to 15,820 rows)

Small Files (<200 rows)

Conclusion: For small files, all approaches perform equivalently (~2ms).

Large Files (10K+ rows)

Conclusion: RustyCSV is consistently 13-28% faster than pure Elixir for large real-world files.

Summary

Speed Rankings by File Type

Strategy Selection Guide

Key Findings

1. Quoted fields show largest gains — 18.6x faster due to SIMD prefix-XOR quote detection handling all escapes in a single pass

2. 5-14x less memory than pure Elixir — Boundary-based parsing uses only 16 bytes per field (offset pairs) on the Rust side, then near-free sub-binary references on the BEAM side. Pure Elixir allocates full copies of every field.

3. BEAM reductions are minimal — 17-24x fewer reductions than pure Elixir, reducing scheduler load (but NIFs can't be preempted)

4. Streaming is 2.2x faster — RustyCSV auto-optimizes File.Stream to binary chunk mode. Also supports arbitrary binary chunks for non-file streams.

5. Real-world vs synthetic — Synthetic benchmarks show 3.5-19x gains; real-world TSV shows 13-28% gains due to simpler data patterns.

Encoding Benchmark Results

dump_to_iodata returns a single flat binary. See the README for usage details and how this differs from pure Elixir.

Throughput

Memory

RustyCSV's BEAM-side allocation is 80 bytes across all scenarios. NIF peak memory is proportional to the output size.

Encoding Summary

Non-UTF-8 encoding shows the largest gains due to single-pass encoding of the entire output buffer.

Running the Benchmarks

# Decode benchmark (all strategies)
mix run bench/decode_bench.exs

# Encode benchmark (all encoding paths)
mix run bench/encode_bench.exs

For memory tracking details, enable the memory_tracking feature:

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

Then rebuild: FORCE_RUSTYCSV_BUILD=true mix compile --force