Templates and Compile Time Computation in Trading Code

Templates and constexpr push decisions to compile time, removing the virtual dispatch and runtime branches a hot path cannot afford to pay for repeatedly.

Templates and compile time computation in trading code exist to move decisions from runtime, where they cost cycles on every message, to compile time, where the compiler resolves them once and generates specialized code with no residual overhead. A function that would otherwise dispatch through a virtual table to decide which instrument type or which pricing rule to apply on every call can instead be written as a template, letting the compiler generate a separate, fully inlined version of the function for each concrete type the program actually uses, with no indirect branch and no runtime decision left behind.

A virtual function call requires the processor to load a pointer to the object's virtual table, then load the function pointer out of that table, and only then jump to the actual function, and each of those loads is a potential cache miss on top of the indirect branch itself, which the branch predictor handles less reliably than a direct call. In code that dispatches through a base class interface once per incoming message, that indirection accumulates the same way a data-dependent branch does, a mechanism covered in the piece on branch prediction and its cost in hot paths.

Templates avoid this because the compiler knows the concrete type at compile time and can inline the call directly, eliminating both the virtual table lookup and the indirect jump entirely, at the cost of generating a separate copy of the function for every type instantiated, a trade known as code bloat that has to be weighed against the latency gain.

The curiously recurring template pattern lets a base class call a method on its derived class at compile time by having the derived class pass itself as a template argument to the base, giving much of the flexibility of an inheritance hierarchy without paying for virtual dispatch at runtime. This pattern shows up in trading code wherever a family of related instrument types or order types shares structure but needs each concrete implementation resolved statically rather than through a runtime interface.

Constexpr functions, expanded significantly since C++11 and further in C++14 and C++20, let a program compute a value during compilation rather than at runtime, provided every input the function depends on is itself known at compile time. A lookup table of tick sizes for a fixed set of instruments, or a set of scaling factors derived from a fixed exchange specification, can be computed once by the compiler and embedded directly into the binary as constant data, so the hot path reads a precomputed value instead of recalculating it on every message.