FastQC: Rust vs Java Benchmark Report

Date: October 2026
Machine: Apple M1 Pro (8 performance + 2 efficiency cores, 16 GB RAM), macOS. Data on an external SSD (~880 MB/s, never the bottleneck).

Implementations:

• Java v0.12.1: the FastQC release most pipelines ran until October 2026. One thread per file, whatever -t is set to.
• Java v0.13.0: adds a parallel pipeline within each file, contributed upstream from this project. Default -t 4.
• Rust v1.0: FastQC-Rust v1.0.1, the previous release. One thread per file.
• Rust v1.1: FastQC-Rust v1.1.0 (#7). Parallel analysis within each file, parallel-capable gzip decoding, default of the available CPUs up to 6. Also measured at -t 2: one analysis thread plus its gzip decoder thread. (These runs were made as -t 1, before the decoder counted towards -t; it is the same configuration.)

Each tool runs at its default settings, one file at a time, one run per file. Java ran on OpenJDK 21 with the launcher's defaults, except that the long-read files got --memory 4096: the default 512 MB heap is too small for them, as FastQC's own help notes. Speedups are relative to Java v0.12.1 unless stated. macOS Spotlight indexing was using about one core in the background throughout; WES results matched earlier runs on a quiet machine to within 2%.

Summary

Average wall-clock speedup over Java v0.12.1 per file, each tool at its default threads.

Test Dataset

Output Correctness

fastqc_data.txt and summary.txt from Rust v1.1 were compared module by module against Java v0.13.0, and between Rust v1.1's -t 2 and default runs. Every file is byte-identical in both comparisons.

Per-File Results

Wall Clock Time

CPU Time (user + system)

CPU time is what a cluster or cloud bill charges for. Java v0.13.0 and Rust v1.1 spend some extra CPU to finish sooner; Rust v1.1 still uses a fraction of the CPU of either Java version.

Peak Memory (RSS)

Rust v1.1 uses more memory than Rust v1.0, because batches of reads are in flight between its threads, but still 3–13x less than either Java version on short reads. Long reads need far more memory in every implementation, because the per-position arrays grow with read length. Java's long-read figures reflect the 4 GB heap it was given: Java v0.13.0 used all of it.

Throughput by Platform

Throughput is compressed file size divided by wall-clock time.

Thread Scaling (Rust v1.1)

One 7.3 GB WES file at each -t value (one run each, measured separately from the table above, after the gzip decoder began counting towards -t):

At -t 1 the file is decoded and analysed on a single thread; from -t 2 the decoder gets a thread of its own.

A single short-read .fastq.gz stops getting faster at about -t 4: from there, the file's one gzip decoder is the slowest stage. One zlib-rs decoder produces about 1.1 GB/s of decompressed data, the same as system gzip. rapidgzip can split a file across several decoders (--decompress-threads), but a normal single-member .gz can only be split speculatively: 4 decoders were 1.35x faster for 2.8x the CPU and ~900 MB of memory, so one decoder per file is the default. Spare cores are better spent on more files at once.

BAM is decoded on the reader thread, which caps it at about 1.6x however many threads it gets.

Where the Time Goes (Rust v1.1)

CPU profile of Rust v1.1 on the 7.3 GB WES file at -t 2: one analysis thread plus its gzip decoder thread, sampled for 40 seconds mid-run with macOS sample (39,386 active samples across both threads, idle waits excluded).

A third of the CPU is gzip decompression, which runs on its own thread. That is why a single file stops scaling at about -t 4: once the analysis is spread across workers, the one decoder is the slowest stage. The analysis side has no single dominant cost any more. The largest remaining item that isn't analysis is UTF-8 validation of each record (about 6%), a possible next step.

What Makes the Rust Version Faster

None of this comes from Rust being inherently faster than Java. Each change was found by CPU profiling and checked for byte-identical output.

1. Parallel analysis within a file

A reader thread parses records and hands batches to worker threads, each of which owns a subset of the QC modules. Every module still sees every read, in order, on one thread, so no results need merging and the output is identical at any thread count. Modules are assigned to workers by their measured cost, so the expensive ones don't share a worker. Batches are capped by bytes as well as by read count, which keeps memory flat on long reads (552 MB → 66 MB on 10 kb reads at -t 8). The same design was ported to Java and shipped in FastQC v0.13.0.

2. Gzip decoding on its own thread

.fastq.gz is decompressed by rapidgzip-core with a zlib-rs inflate, on a separate thread from the parser, so decompression overlaps with the analysis from -t 2. At -t 1 it runs on the reading thread. A 1 MiB read buffer keeps hand-offs between the two rare. Everything is pure Rust: there is no system zlib to link.

3. One SIMD pass for every adapter

FastQC looks for six adapter sequences in every read. Java calls String.indexOf() once per adapter. Rust v1.0 used SIMD memchr per adapter; Rust v1.1 finds all of them in a single pass with aho-corasick's Teddy algorithm, 3.6–5.2x faster again. Hits are tallied once per read at the first match position and summed at the end, instead of incrementing every later position.

4. Vectorised counting

Base counts and each read's lowest quality are computed in loops the compiler turns into SIMD instructions. In the per-position modules, a 256-byte lookup table maps each base straight to a counter index, replacing branch chains the CPU can't predict on random DNA. Together these cut CPU by about a third on 300 bp reads.

5. No per-read allocation

Java creates several objects for every read: a Sequence, a new String from toUpperCase(), String[] arrays from split(":") for tile parsing. Rust parses FASTQ lines straight into reused buffers with a SIMD newline search, uppercases in place, and reads tile IDs without allocating. With no garbage collector, there are no GC pauses.

Could these improvements be back-ported to Java?

Parallel analysis: yes, and it has been. FastQC v0.13.0 ships the same reader-plus-module-workers pipeline (s-andrews/FastQC#197) and removes per-sequence char[] allocations in seven modules (#199). That is where 0.13.0's speedup over 0.12.1 comes from.

The per-read optimisations were tried in Java in April 2026 and didn't carry over:

• SIMD adapter search: no. Java has no portable way to call NEON or SSE substring search, and String.indexOf() is already a HotSpot intrinsic. A hand-written char[] loop was slower (16.0s vs 12.9s). The Vector API is still incubating and has no substring search.
• Lookup-table base counting: marginal. HotSpot already compiles small switch statements on bytes into jump tables. An explicit array lookup measured about 3% faster.
• Zero-allocation processing: structurally limited. Java strings are immutable and heap-allocated, so toUpperCase() and split() must allocate. Workarounds measured negligible gains, since HotSpot's escape analysis and generational GC already handle short-lived objects well.

Single-threaded, Java v0.13.0 is about 14% slower than 0.12.1 on the WES file (522s vs 456s, reproduced on a quiet machine): the cost of the pipeline when it has only one thread to run on.

Build

FastQC-Rust v1.1 has a single build: pure Rust, with no C toolchain and no system libraries, so binaries are fully static on every platform. The native-zlib feature and the separate pure-Rust variant from 1.0 are gone. BAM (via noodles) and Fast5 decode through the same zlib-rs backend.

Overall Summary

Real-World Impact

To put these numbers in context, we analysed FastQC task execution data from Seqera Platform Cloud, which runs Nextflow pipelines at scale for bioinformatics teams worldwide.

Scale of FastQC usage (Seqera Platform Cloud only)

Projected savings

Cloud and cluster costs follow CPU time, not wall time. On the short-read files, Rust v1.1 uses 3.7x less CPU than Java v0.12.1, the version behind that usage data. Applied to the annualised Seqera Cloud usage alone:

* Estimated at $0.03/CPU-hour (typical cloud spot pricing for compute-optimised instances).
** Estimated using global average grid carbon intensity (0.35 kgCO2/kWh) and ~200 W per CPU core.

Beyond Seqera Platform

These figures cover a single cloud platform. FastQC runs in university clusters, hospital genomics labs, national sequencing centres and cloud pipelines worldwide, so the total compute spent on it is likely orders of magnitude larger.

The memory reduction matters too: a short-read FastQC task that needed ~500 MB fits in ~50 MB, so it can run on smaller instances and packs more densely in schedulers like Kubernetes and AWS Batch.