I wonder if it's Zig or musl that's to blame; did you end up statically linking with musl using musl-gcc, or did you forego static linking entirely?

It's well-known that musl is in general much, much slower than glibc. People keep rediscovering that for some reason, likely because they hear of stuff like old echoes of Usenet posts ranting against glob "bloat", not being aware that a lot of what people call bloat is specialization of a lot of performance-sensitive algorithms to leverage SIMD, special-casing, math optimisations, etc. When you check the glibc mailing lists, it's obvious performance is a predominant concern.

I've heard you can just swap out allocators pretty easily - did something prevent this? Or perhaps its not as straightforward as I've thought...

I’ve experienced the same performance issues with cgo + a library compiled with zig cc. IIRC it seemed like an issue with the zig tooling not plumbing the optimization flags through the ancient autotools build system for our required dependency. After a while fiddling, we just rolled it back too.

I haven’t tried this in about a year, so maybe the tooling doesn’t have these issues now.

This sounds like the musl allocator. Using mimalloc or jemalloc would probably fair a lot better.

Is this a problem in distributions that use musl as the system libc (Alpine) ?

Interesting...

I have been building & using a statically compiled tailscale (with CGO) for a while but didn't notice any performance hits. Script: https://github.com/Azathothas/Toolpacks/blob/main/.github/sc...