C vs Rust performance comparison in the SQLite parse_number extension

Summary

Simon Willison compared four different versions (two in C, two in Rust) of SQLite's parse_number() extension. The C implementation using Clinger's fast path achieved 16–19 ns per line, roughly twice as fast as the Rust versions. All four implementations successfully passed 8 million fuzz tests. The entire experiment, from initial prompt to final research report, was orchestrated by Claude Opus 5.5.

Why it matters

This result provides a concrete and reproducible data point for the debate between C and Rust in systems programming. It suggests that language choice matters less than the specific parsing algorithm employed. Additionally, it demonstrates a practical workflow where an LLM end-to-end builds, optimizes, and documents a systems-level micro-benchmark. This approach lowers the barrier for developers who want to extend SQLite without deep C expertise.

Highlights

• Optimized C (Clinger's fast path): 16–19 ns per line; both Rust contexts ranged from 32–55 ns; plain C using strtod() was the slowest at 67–106 ns.
• The binary size difference is striking: the C .so file is 14 KB, while Rust builds range from 298–321 KB, a 20x difference.
• All four implementations produced identical results across 8 million fuzz tests, confirming accuracy parity despite performance differences.

Critical take

The headline 'C beats Rust' actually means 'a hand-tuned fast path beats a library call.' This comparison conflates algorithm selection with language choice. Furthermore, the entire codebase was generated by an AI in a single chat session, making the term 'research report' generous. It remains unclear whether an experienced C developer could reach the same result without the LLM's iterative prompting.