Michael Stapelberg finally achieved a years-long goal for Debian Code Search: deleting its last cgo dependency. For seven years the search engine called the TurboPFor C library for integer compression; Go 1.26’s new experimental simd/archsimd package finally made AVX-512-class SIMD reachable from plain Go, so he reimplemented the codec natively.
The post is a model performance-engineering retrospective:
- Audit actual usage before optimizing — the decoder looked like the hot spot, but the query path tolerated 10-100ms of regression; reducing allocations and specializing per bit width was enough there
- The encoder (used for partial indexing and full-index merges) was where raw speed mattered — a native Go version hit 76% of C in a few days
- SIMD kernels plus bit-width specialization beat the old cgo path in 2-3 commits
- A positional-popcount technique for block scanning delivered another 2x
- Apples-to-apples against clang-compiled C, Go is about 1.4x slower — but versus what DCS actually shipped, pure Go matched or exceeded it
- Value decoding runs at 7 instructions per cycle on hardware capped at 8
He also catalogues the Go compiler costs with real nuance: bounds checks cost performance but stay on for safety, mid-stack inlining NOPs slow dispatch-bound functions, and you cannot target a specific microarchitecture — so Intel-era POPCNT workarounds tax AMD Zen users too.
Two things stand out beyond the numbers. First, the discipline of measuring call paths instead of optimizing intimidating function names. Second, his process note: he used a coding agent for the tedious parts (reading objdump output, running endless experiments) but refused to let it own the code — “I don’t want to vibe-code Debian Code Search” — reviewing and hand-verifying every optimization himself. A useful, honest example of LLM-assisted performance work.