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.
Was das für dich bedeutet
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.
Quellen
- 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
Automatisch aus den obigen Quellen geschrieben, dann von unserem Code geprüft: Jede Zahl und jeder Name muss darin vorkommen, und kein Satz darf eine Quelle kopieren. Einen Fehler entdeckt? Melde ihn.
Welche KI kannst du heute kostenlos nutzen?
Jedes kostenlose KI‑Modell, bewertet durch blinde menschliche Stimmen, mit dem Speicher und der Geschwindigkeit, die es auf deiner eigenen GPU benötigt.