Selecting a method from the receiver's runtime type costs more than calling a fixed function. Compare how these four runtimes claw that cost back, and what each gives up: Rust's choice between monomorphised generics and dyn Trait objects; a C++ compiler that can devirtualise only under link-time optimisation or an explicit final marker; the HotSpot JVM's inline caches and speculative devirtualisation backed by deoptimisation; and the per-class method caches in Objective-C's objc_msgSend and in Ruby.

## What a virtual call actually costs A call resolved from the receiver's runtime type usually compiles to: load a pointer to the type's method table from the object, load the slot for this method, jump to it. On a modern out-of-order CPU with a branch target buffer, a call site that keeps hitting the same target predicts well and the extra loads are hidden. The cost that matters is **the optimisations you never get**. A direct call can be inlined; once inlined, the compiler sees the callee's body in the caller's context and can fold constants, prove an object never escapes and stack-allocate or eliminate it, unroll a loop, or delete a branch. An unresolved call is an opaque wall: arguments must be materialised, registers spilled, the heap assumed clobbered. Measured naively the indirect jump looks like a couple of cycles; measured in a hot loop, the missing inlining can be an order of magnitude. Every technique below exists to recover inlining, not to shave the jump. A second cost appears only at **megamorphic** sites (many receiver types through one call). There the indirect branch stops predicting and you eat mispredictions plus method-table cache misses. ## Rust: the choice is in the source Rust splits the decision and hands it to the programmer. Writing `fn draw<T: Shape>(s: &T)` monomorphises: the compiler emits a separate copy of `draw` for every concrete `T` used, each with a direct, inlinable call. Writing `fn draw(s: &dyn Shape)` builds a fat pointer (data pointer plus vtable pointer) and does one indirect call from one copy of the code. Monomorphisation is not free: binary size grows with the number of instantiations, compile times grow with it, and a large instantiated blob can thrash the instruction cache badly enough that the `dyn` version wins. This is why the choice is a real engineering decision, not a default. ## C++: devirtualisation as a proof obligation C++ has no runtime to observe behaviour, so the compiler may only devirtualise when it can *prove* the target. It can when the object's exact type is visible (`Circle c; c.area();`), when the class or the method is marked `final`, or when it sees the whole program. Without link-time optimisation, each translation unit must assume some other unit defines an override, so an ordinary virtual call through a base pointer stays virtual. With LTO or whole-program visibility the compiler can see the closed hierarchy, and GCC and Clang additionally do *speculative* devirtualisation: emit a guarded direct call to the likeliest target with a fallback to the indirect call. Note the divergence from Rust: in C++ the optimisation is a property of your build configuration, not of your source. ## HotSpot: speculate, verify, and be able to undo A JIT can do something no ahead-of-time compiler can: look at what has actually happened. HotSpot uses class-hierarchy analysis (if an interface currently has exactly one loaded implementor, the target is unambiguous *right now*) and per-call-site inline caches recording the receiver types observed. A call site that has only ever seen one type is monomorphic and gets a type guard plus a fully inlined body; two types can be handled bimorphically with two guarded branches; beyond that the site is declared megamorphic and falls back to a table lookup with no inlining. Because these are guesses, they need an undo. Compiled code records dependencies ("interface I has one implementor"). When a plugin loads a second implementation, the class loader invalidates the dependency, marks the compiled method not-entrant and **deoptimises** any live frames back to the interpreter, and the method is recompiled with a guard or a table lookup. The operational consequence: a hot path can get slower with no code change and no configuration change, purely because a new type was loaded. It also makes microbenchmarks lie: warm one implementation, measure inlined code, then ship into a process where three exist. ## Objective-C and Ruby: cache, then flush Where classes are mutable at runtime, nothing can be proved at all. Objective-C's `objc_msgSend` resolves a selector against the receiver's class and keeps a per-class cache of recent selector to implementation mappings; a hit is a few instructions. Ruby uses inline caches at call sites, validated against class and global serial numbers. In both, defining, replacing or swizzling a method invalidates caches: per class in Objective-C, and via serial bumps that can invalidate broadly in Ruby. Mutating classes after start-up therefore costs far more than the mutation itself, which is why frameworks do their patching once during boot rather than lazily. ## Why final-by-default helps AOT more than JIT Kotlin classes and C# methods are non-virtual unless you opt in. For an ahead-of-time backend (Kotlin/Native, .NET NativeAOT, Android's AOT compilation) that sealing is exactly the proof the compiler lacked, the same benefit as C++ `final`. On HotSpot it buys much less, because class-hierarchy analysis already discovers that a class has a single implementor and inlines on that basis; the JIT knows the *actually loaded* hierarchy, which is strictly more information than the declaration. What sealing still buys on a JIT is stability: fewer invalidations, fewer deoptimisation storms when new code loads. ## Operating it Diagnose before you restructure: check whether the hot site is monomorphic or megamorphic, whether compiled code is being repeatedly discarded, and whether the regression coincided with a class or plugin being loaded. Then the fixes are ordinary: split a megamorphic site so each copy sees one type, hoist the dispatch out of the loop, or seal the hierarchy. Not "remove polymorphism".