Pursuing C-Level Performance with Pure Functional Programming

Date: October 22, 2026

In a previous analysis titled "Why Lean is Faster Than Rust," the author highlighted a startling achievement: a DEFLATE compression library developed in Lean 4 (a functional language and proof assistant) actually outperformed a Rust-based equivalent. This is particularly notable given that the Rust package in question has surpassed a billion downloads on crates.io.

As noted in the original piece:

lean-zip beats every single compression level miniz_oxide provides, i.e. we're capable of providing the same compression at higher throughput. At its fastest setting we're 15% quicker and the output is 8.8% smaller.

The "Final Boss" of Performance

Despite the victory over Rust, lean-zip encountered a ceiling when facing the industry gold standard for DEFLATE: libdeflate. Written in C, libdeflate remains the undisputed champion.

The reason for this gap is technical: libdeflate utilizes highly tuned, architecture-specific SIMD (Single Instruction, Multiple Data) instructions. Because Lean cannot easily access these low-level hardware optimizations, it simply cannot compete with the raw speed of C in this specific domain.

---

Enter Roc: A New Challenger

This brings us to Roc, a functional programming language designed specifically for runtime efficiency (though, unlike Lean, it is not a theorem prover).

Roc's guiding philosophy is summarized in its tagline:

"Fast, Friendly, Functional"

The priority is clear: Fast comes first. Both execution speed and compilation time are core design objectives. It is important to note that Roc is still in its infancy:

• It has not yet reached its first numbered release (v0.1.0 is still weeks away).
• The package ecosystem is nascent.
• Extensive optimization has been performed on most packages. $\rightarrow$ Almost no optimization work has been done on the ecosystem yet.

Despite this, the author believed that Roc's fundamental language design, its existing optimizations, and its fresh compiler implementation provided a strong enough base to challenge libdeflate.

The Optimization Process

The author focused on roc-deflate, a package created by Niclas Ahden (who utilizes it in professional, paid production environments). The goal wasn't necessarily to obliterate surpass C across every metric, but to see how narrow the gap could be.

The Methodology:

• Focus on non-streaming APIs (streaming is not yet implemented in roc-deflate).
• Utilize the standard Silesia corpus for benchmarking.
• Verify that the output remained bit-identical to the original.
• Perform iterative performance grinding.

# Hypothetical benchmarking command used during the process
./roc-deflate-bench --corpus silesia --level 1 --iterations 15

---

The Results: Closing the Gap

The benchmarks were conducted on two different architectures to ensure a broad comparison: a 2021 M1 MacBook Pro and an AMD Ryzen 9 3900X running Ubuntu.

Across 144 different benchmarks, roc-deflate was slower than libdeflate on average, but the margin was surprisingly slim. The median performance gap can be expressed as:

$\text{Performance Gap} = \frac{\text{Time}_{\text{Roc}} - \text{Time}_{\text{C}}}{\text{Time}_{\text{C}}} \times 100$

• Ryzen 3900X: $\approx 8.9\%$ slower.
• M1 MacBook Pro: $\approx 2.6\%$ slower.

Performance Comparison Table (L1 Compression)

The following table illustrates the throughput (MB/s) for various files within the Silesia corpus at the L1 compression level.

Performance Hierarchy

The following diagram represents the relative performance tiers observed in these DEFLATE implementations:

Final Analysis (L2 Compression)

The trend continued into L2 compression. For example, on the dickens file, libdeflate achieved 161.68 MB/s, while roc-deflate followed closely at 143.60 MB/s. This suggests that a pure functional language, when designed with a "performance-first" mentality, can operate within a very narrow margin of the most optimized C code available.