Shlemiel the Painter Is Back: How Zig’s libc Rewrite Made SQLite Slower
75 points by ohrv
75 points by ohrv
Relevant issue: https://codeberg.org/ziglang/zig/issues/37402
Pending PR: https://codeberg.org/ziglang/zig/pulls/37417
That’s a lovely way of explaining quadratic time operations. I took a quick look at the linked zig code, and presumably it’s like this because it’s mapping c strings into nice safe zig arrays rather than treating them as unsafe streams of memory locations containing chars.
From one build and deploy script on my Mac I can target all of my platforms without containers or build machines. Zig’s elegant libzigc re-implements the standard library so you can static link the necessary functionality.
Zig uses musl (the standard library rewrite), but they have been rewriting it piece by piece in pure Zig (via libzigc), removing the C dependencies one at a time.
Hmm, was this using the musl triple when invoking zigbuild? I'd be a bit surprised if that didn't use musl, but I'm not sure what other libc values can be used in the triple other than glibc.
Zig treats triples as requesting an ABI, rather than an implementation. A member of the core team discussed the rationale behind it in this Lobsters comment.
The quoted text is correct, you can follow the link to the commit and see that musl sources are deleted as libzigc symbols are added. This is also done for symbols provided by compiler_rt.
Relevant issues: https://github.com/ziglang/zig/issues/2879 -> https://codeberg.org/ziglang/zig/issues/30978
Hate to say it, but LLM code review certainly would have caught such an obvious "accidentally quadratic" bug.
And we would have missed the community showing up, and having fun working together on a fix.
I think this is acceptable in a pre-1.0 language.
You don't even need that. You just need a ratio gate.
Measure the time it takes for a function to process 1x an input (which is basically "setup time"), 10x an input, 100x an input, and 1000x an input. If you want to get fancy, warm it up first with 10000x input to get to steady-state performance.
Measure the ratios between those times. (This should be somewhat cpu-details-orthogonal and somewhat immune to load effects.) Is it linear? n log n? n squared? Derive a complexity score from that (within a bit of tolerance). Force it to be under a certain score.
Done.