Virtual functions and vtables

A class with virtual functions gets a table of function pointers, one table per class, generated by the compiler. Each object of the class carries a hidden pointer to its class's table, usually as the first eight bytes of the object. A call through a base reference becomes three steps:

struct Strategy {
    virtual ~Strategy() = default;
    virtual void on_quote(const Quote& q) = 0;
};

void dispatch(Strategy& s, const Quote& q) {
    s.on_quote(q);   // load s's vptr, load slot 1 of the table, call that address
}

So "are virtual calls slow?" has a precise answer. A virtual call costs two dependent loads, an indirect jump the CPU must predict, and the loss of inlining.

The loads are usually cheap. If the same few objects are called repeatedly, their vtables sit in L1 like any other hot data. The jump is predicted well when a call site keeps going to the same target, which is the common case: a strategy process often runs one strategy class.

The real cost is the lost optimisation. A small virtual function that could have been inlined into a loop becomes an opaque call. The compiler cannot hoist work out of it, vectorise around it, or assume anything about what it touches in memory. In a tight loop over thousands of quotes that can matter far more than the dispatch itself.

The cost rises when one call site sees many types in an unpredictable order: an array of mixed shapes, a heterogeneous list of event handlers. Then the indirect jump mispredicts regularly as well.

Compilers devirtualise calls when they can prove the dynamic type:

• The object is a local or a member whose type is known at the call site.
• The class or the function is marked final, so no override can exist.
• With link-time optimisation and whole-program analysis, a class with no further subclasses.

struct Momentum final : Strategy {
    void on_quote(const Quote& q) override;
};

void run(Momentum& m, const Quote& q) {
    m.on_quote(q);   // final: the compiler knows the target, can call directly and inline
}

When the set of types is known at compile time, trading code usually avoids runtime dispatch on the hot path:

• Templates. Make the engine a template on the strategy type. Each instantiation calls its strategy directly and can inline it.
• CRTP. A base class template that calls the derived class through static_cast, giving shared code without virtual calls. Module 3 covers it with templates.
• std::variant and std::visit. A closed set of types, stored by value, dispatched by an index the compiler can turn into a jump table or a series of compares.
• Grouping by type. Keep one vector per concrete type and loop over each, so every call site sees one target.

None of these is free. Templates increase compile time and code size; variants make the object as large as the largest alternative. Virtual functions remain the right tool for things that happen rarely, such as configuration, start-up and administration.