FreeLLMC and Rust SQLite parse_number extensions benchmark shows fast C beats Rust
A study of four parse_number() SQLite extensions finds a compact C fast‑path runs at 16–19 ns per row, twice as fast as Rust versions.
Simon Willison compared four SQLite scalar functions named parse_number() that strip commas, currency symbols and percent signs, handle a leading minus, and return NULL for unparsable strings.
The implementations include plain C (using strtod()), a C fast‑path version, a Rust version built with rusqlite, and a Rust version built with sqlite-loadable. All behaved identically across 8 million fuzz tests.
On a 2 vCPU Linux VM (SQLite 3.53.1), the plain C version cost 67 ns per row on mixed data, while the fast‑path C version achieved 16–19 ns per row, about twice the speed of the Rust variants (41–46 ns).
The fast‑path C extension is also far smaller: the .so file is 14 KB versus roughly 300 KB for the Rust builds. Rust code is shorter (30–36 lines plus a shared parser) but carries the standard library, increasing binary size.
What it means for you
For developers extending SQLite, a compact C fast‑path offers the best performance and smallest footprint, useful for embedded or resource‑constrained deployments. Users of free or local AI tools can benefit from faster numeric parsing in data pipelines that rely on SQLite, while the Rust versions provide safer code at the cost of larger binaries.
Sources
- parse_number() as a SQLite extension: C vs Rust, Simon Willison, 8 Nov 2026
- research/sqlite-parse-number-c-vs-rust at main · simonw/research · GitHub, github.com (official), 8 Nov 2026
Written automatically from the sources above, then checked by our code: every number and name must appear in them, and no sentence may copy a source. Spotted a mistake? Report it.
Which AI can you use for free today?
Every free AI model, ranked by blind human votes, with the memory and speed it needs on your own GPU.