Abstract:

This analysis measures the performance cost of various closure implementations—C++ Lambdas, Apple Blocks, and GNU Nested Functions—when solving the "userdata" problem, specifically using Knuth’s recursion-heavy Man-or-Boy test. The results clearly demonstrate that implementations providing the compiler with the most static information (non-type-erased C++ Lambdas) yield maximum efficiency. Conversely, certain widely cited solutions are catastrophically slow: the default GNU Nested Function implementation is an "optimizer-murderer" due to its executable stack design, and the naive Rosetta Code C++ lambda implementation is several orders of magnitude slower because it repeatedly copies expensive, allocating closure objects. Standardization efforts for ISO C should focus on non-allocating, statically-knowable callable types, similar to C++'s std::function_ref, to avoid these performance pitfalls.

The Cost of Closures in C: Performance Breakdown and Design Critique

• The Closure Problem (Preamble): Closures are constructs that allow functions to capture and use data outside of their explicit arguments. The standard C approach of relying on static or global variables is untenable for complex programs due to thread contention and state management issues.
• The Benchmark: Man-or-Boy Test (Anatomy of a Benchmark): Performance is measured using the Man-or-Boy test, which heavily stresses recursion, self-reference, and local data access. Measurements rely on Google Benchmark and external libraries to defeat compiler optimization (ret -67).
• Performance Winner: Non-Erased Lambdas (Lambdas: On Top!): Non-type-erased C++ Lambdas (using templates, often requiring C++23's Deduced This or similar techniques) are the fastest implementation. The compiler gains "perfect information" about the recursive call chain, allowing for extreme optimization and inlining. This is a clear indicator that providing the compiler full static context yields maximal performance.
• Efficiency Tradeoff: Slim Type Erasure (Lambdas: Type-Erased): Using non-allocating type erasure, specifically std::function_ref, results in only a slight performance penalty compared to the optimal non-erased lambda. This confirms that a slim, non-owning "view" type (analogous to a proposed C wide function pointer) is an excellent and efficient generalization for closures.
• Catastrophic Failure: Rosetta Code Lambdas (Lambdas: On…. Bottom, too?): The specific implementation from Rosetta Code using std::function with a default copy capture ([=]) is "unbelievably awful," showing performance several orders of magnitude worse than any other solution. Key takeaway: Defaulting to copy-capture ([=]) is disastrous when the captured arguments are expensive, allocating types like std::function.
• Optimizer Death: GNU Nested Functions (Nested Functions and The Stack): GNU Nested Functions perform drastically poorly—worse than allocating types—by an order of magnitude or more. The implementation relies on an executable stack to house the trampoline, which actively murders crucial compiler optimizations like frame pointer omission and register promotion.
  • Detail: I don't care about the historical context; the current implementation is objectively inefficient and creates serious security implications (executable stack). A new heap-based implementation is pending but untested; probability suggests its performance ceiling will likely only match Apple Blocks, not the C++ Lambda variants.
• Mediocre Option: Apple Blocks (What about Apple Blocks?): Apple Blocks are the best of the C extensions tested, but slower than even raw C functions using a custom context struct (ARG*). The performance cap is likely due to the overhead of the Blocks Runtime and necessary ARC (Automatic Reference Counted) management, even when allocations are minimized by keeping blocks on the stack.
• The Ideal C Solution (Learned Insights): The data suggests that for high-performance C, a standardized, thin, non-allocating "Wide Function Pointer" is required. This type, conceptually similar to a { function_pointer, context_pointer } pair, should be backed by the compiler to allow low-cost conversion from existing extensions (GNU, Apple, C++). Standardizing this would solve the long-standing "userdata" problem efficiently.