June 23, 2026
ffi-ght club in the comments
Performance Improvements in Libffi
This speed boost had coders asking: wait, why wasn’t it doing this already
TLDR: libffi now speeds up repeated calls by remembering the setup work instead of recalculating it every time. Commenters immediately split into two camps: people shocked it didn’t already work this way, and people pitching totally different solutions.
A niche software tool just got a clever speed makeover, and the real fireworks came from the comment section. The update to libffi is basically about making repeated function calls less wasteful: instead of re-figuring out where every piece of data should go every single time, it now builds a reusable “plan” once and follows that on later calls. In plain English: less rethinking, more doing. No risky write-and-run code tricks, no flashy code generation at runtime — just a smarter memory of what was already learned.
But the community didn’t just nod politely. One of the loudest reactions was a baffled “wait, wasn’t this supposed to be prepared already?” from users who saw the existing setup step and assumed it handled the hard part. That instantly turned the thread into a mini roast of software naming, with commenters basically asking whether “prepare” had been overselling itself for years. Others jumped in with classic engineer energy: if many people call the same known functions again and again, why not build the fast path ahead of time instead? And then came the calm counterpoint from the “bytecode fans,” praising this as an old-school, elegant trick that avoids security headaches while staying small and practical.
So yes, the code got faster — but the comments gave us the real drama: confusion, armchair redesigns, and a little nostalgic nerd joy over a humble trick that made people say, “Oh, that’s actually pretty neat.”
Key Points
- •The article describes libffi as an interpreter for calling conventions that resolves argument placement from runtime-provided function signatures.
- •libffi currently stores only stack frame size and return-value handling in `ffi_prep_cif`, while discarding computed per-argument placement information.
- •Each `ffi_call` recomputes argument classification and placement, which the article says can take about 650 bookkeeping instructions for a three-argument call on x86-64.
- •The repeated classification work involves walking type descriptors, recursively analyzing structs, and applying System V AMD64 ABI rules to assign arguments to INTEGER, SSE, or stack locations.
- •The proposed optimization is a per-signature plan encoded as a flat list of simple move operations, allowing later calls to execute precomputed argument moves without JIT code generation.