Zig's Pure-Zig libc Made SQLite About 12,000x Slower on a 1.2 MB Input, and the Fix Has No Benchmark Yet

A developer building SQLite through zig cc for Linux found that tokenizing a 1.2 MB input ran about 12,000 times slower than the same code built against musl. Dennis Forbes put the figure in a post dated October 26, 2026 titled "Shlemiel the Painter Is Back." The number is the author's own and the post gives no absolute timings.

Forbes was running a Rust service backed by SQLite for chess analysis. Runners return large sets of JSON bundles, and about 40,000 records took minutes to insert while one CPU core stayed saturated. He builds for Linux with cargo-zigbuild, which compiles SQLite with Zig's C compiler.

Where the time goes

Zig has been rewriting its libc in Zig. In the rewritten strspn, strcspn, strpbrk and strstr, the function first measures the entire string and then scans. A tokenizer that skips whitespace calls such a function once per token, so every call pays for the full remaining input. The cost grows with the square of the file size, the pattern the post's title names after the old joke about a painter who walks back to the paint can every time.

The post cites two Zig commits: ae9a8acc7f232cb78a131b6dc05633f34d0990ad for the strspn rewrite in lib/c/string.zig, and f0649dd9782780f5b608af338b6d4add19ce2730 for the replacement with the pure-Zig variant. It says the problem appeared on Linux and never on his Mac, where Zig was not compiling SQLite.

The post does not state the Zig version, the SQLite version or reproduction steps. Without them, nobody can say yet which releases carry the pattern. Zig's download page lists 0.17.1 as the latest stable release, dated November 2, 2026, and says nothing about the libc rewrite.

The workaround and the pending fix

Forbes's workaround was to strip whitespace from the JSON before inserting it, and to build Linux targets inside Linux containers. He mentions no upstream fix.

One is in progress. Pull request 37417 on Codeberg, titled "ziglibc: fixed strchr, strchrnul and others looping over multiple times the string when not needed," was opened on October 26 by a first-time contributor, godwers, and contributes to issue 37402. It is open, with changes requested by andrewrk, who asked for machine code output for the affected functions along with musl for comparison. The disassembly posted so far covers the Zig side only, and the PR carries no timing results.

Function group	Change in the PR
strchr, strchrnul, index	Single pass, no rescanning
strrchr, rindex	Calls memrchr, as musl does
strspn, strcspn, strpbrk, strsep, strtok_r, strcasestr	Fewer loop passes
wcschr, wcsspn, wcscspn, wcspbrk, wcstok	Wide-character equivalents

On a Ziggit thread opened on November 4, the user nonzeroq linked the PR as "a PR to solve some of these issues that was filed recently." The page shows no comment from a Zig maintainer, and it does not say whether the PR has merged.

Who is exposed

The affected group is narrow and specific: Linux builds that compile C code with zig cc against Zig's own libc, and that call the string-scanning functions in a loop over a large buffer. SQLite's tokenizer is one such caller. Anyone building SQLite with GCC or Clang against glibc or musl is not in the post's scope.

The 12,000x figure is a ratio from one input, measured by one person, and the PR has not yet shown that it closes the gap. The same caution applies to Nvidia's 90% build-time claim for Auto Ontology, which also arrived without a published method. Database teams that have already moved engines for performance, such as PostHog's move off DuckDB, at least published their snapshot counts.

If you ship zig cc builds of SQLite for Linux, time a 1 MB insert against a musl build before the next release. The pull request's next step is andrewrk's requested musl comparison, with no date set.