Predicting inlining behavior for nested functor applications

Functor Application Overhead

In OCaml, functors allow modules to be parameterized by other modules. When these functors are applied, the compiler must decide whether to inline the application or rely on dynamic dispatch. In scenarios involving deeply nested functor chains, the overhead of dynamic dispatch can become a significant performance bottleneck.

Compiler Heuristics and Inlining

The OCaml compiler employs internal heuristics to determine which functor applications are inlined. However, these heuristics are not explicitly detailed in the language reference, making it difficult to ensure that critical paths are optimized without relying on trial-and-error profiling with tools like ocamlprof.

Given the variations in compiler behavior across versions (such as OCaml 4.14 or 5.0), it is unclear how to reliably trigger inlining for complex nested structures without globally increasing inlining limits.

• What specific criteria does the OCaml compiler use to decide if a functor application should be inlined?
• Is there a mechanism to force inlining for a specific functor application rather than adjusting global compiler flags?