ffi_call_plan caching for GLib

# ffi_call_plan caching for GLib Source: [https://blogs.gnome.org/chergert/2026/07/24/ffi_call_plan-caching-for-glib/](https://blogs.gnome.org/chergert/2026/07/24/ffi_call_plan-caching-for-glib/) [Skip to content](https://blogs.gnome.org/chergert/2026/07/24/ffi_call_plan-caching-for-glib/#content) About a month ago[Anthony Green](https://atgreen.github.io/repl-yell/)added a novel “call plan” to[libffi](https://github.com/libffi/libffi)\. This allows one to cache the hard work of determining what to do once and skip all of that work in subsequent calls\. You can read more of the details[on their article about it](https://atgreen.github.io/repl-yell/posts/libffi-plan-cache/)\. The best case for me was about a 25% reduction in amortized overhead for`GClosure`invocation\. In some less ideal situations it was still about a 10% reduction\. Not bad\! A[merge request for GLib is here](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5256), though it will likely require some build system triage since it requires the newest libffi for CI to unblock it\. I also[patched`libffi`to add frame\-pointers](https://gitlab.gnome.org/-/snippets/7847)so I can unwind across ffi boundaries from the Linux perf unwinder\. Very handy if you want, you know, to profile your system in a useful manner\. And repeated testing here showed about the same \(or shockingly less\) overhead than the counter\-parts\. Modern CPU sure are interesting beasts\. ## Post navigation