{"slug": "devirtualization-and-static-polymorphism", "title": "Devirtualization and Static Polymorphism", "summary": "This article explains that virtual dispatch in C++ incurs performance costs due to pointer indirection, larger object sizes, and inhibited inlining. It describes how compilers can sometimes devirtualize calls automatically, and how developers can manually replace dynamic polymorphism with static polymorphism using techniques like the `final` keyword, whole-program optimization (`-fwhole-program`), or link-time optimization (`-flto`) to resolve calls at compile time for zero runtime overhead.", "body_md": "Ever wondered why your \"clean\" polymorphic design underperforms in benchmarks? Virtual dispatch enables polymorphism, but it comes with hidden overhead: pointer indirection, larger object layouts, and fewer inlining opportunities.\n\nCompilers do their best to *devirtualize* these calls, but it isn't always possible. On latency-sensitive paths, it's beneficial to manually replace dynamic dispatch with *static polymorphism*, so calls are resolved at compile time and the abstraction has effectively zero runtime cost.\n\n## Virtual dispatch\n\nRuntime polymorphism occurs when a base interface exposes a virtual method that derived classes override. Calls made through a `Base&`\n\nare then dispatched to the appropriate override at runtime. Under the hood, a virtual table (`vtable`\n\n) is created *for each class*, and a pointer (`vptr`\n\n) to the `vtable`\n\nis added *to each instance*.\n\nOn a virtual call, the compiler loads the `vptr`\n\n, selects the right slot in the `vtable`\n\n, and performs an indirect call through that function pointer. The drawback is that the extra `vptr`\n\nincreases object size, and the indirection through the `vtable`\n\nmakes the call hard to predict. This prevents inlining, increases branch mispredictions, and reduces cache efficiency.\n\nThe best way to observe this phenomenon is by inspecting the assembly 1 code emitted by the compiler for a minimal example\n\n``` php\nclass Base {\npublic:\n  auto foo() -> int;\n};\n\nauto bar(Base* base) -> int {\n  return base->foo() + 77;\n}\n```\n\nFor a non-virtual member function `foo`\n\nlike in the example above, the free function `bar`\n\nissues a direct call\n\n```\nbar(Base*):\n        sub     rsp, 8\n        call    Base::foo()  // Direct call\n        add     rsp, 8\n        add     eax, 77\n        ret\n```\n\nHowever, declaring `foo`\n\nas `virtual`\n\nchanges `bar`\n\n's assembly into an indirect, vtable-based call\n\n```\nbar(Base*):\n        sub     rsp, 8\n        mov     rax, QWORD PTR [rdi]  // vptr (pointer to vtable)\n        call    [QWORD PTR [rax]]     // Virtual call\n        add     rsp, 8\n        add     eax, 77\n        ret\n```\n\n## Devirtualization\n\nSometimes the compiler can statically deduce which override a virtual call will hit. In those cases, it *devirtualizes* the call and emits a direct call instead (skipping the `vtable`\n\n). For example, devirtualization is straightforward 2 when the runtime type is clearly fixed\n\n``` php\nstruct Base {\n  virtual auto foo() -> int = 0;\n};\n\nstruct Derived : Base {\n  auto foo() -> int override { return 77; }\n};\n\nauto bar() -> int {\n  Derived derived;\n  return derived.foo();  // compiler knows this is Derived::foo\n}\n```\n\nThe compiler is able to devirtualize even through a base pointer, as long as it can track the allocation and prove there is only one possible concrete type. The problem is that with traditional compilation, object files are created per translation unit (TU)---compiled and optimized in isolation. The linker simply stitches those objects together, so cross-TU optimizations are inherently limited. That's where compiler flags are useful.\n\n`-fwhole-program`\n\n: tells the compiler \"this translation unit is the entire program.\" If no class derives from `Base`\n\nin this TU, the compiler is free to assume nothing ever does, and can devirtualize calls on `Base`\n\n.\n\n`-flto`\n\n: link-time optimization. Keeps an intermediate representation in the object files and optimizes across all of them at link time, effectively treating multiple source files as a single TU.\n\nOn the language side, `final`\n\nis a lightweight way to give the compiler the same guarantee for specific methods\n\n``` php\nclass Base {\npublic:\n  virtual auto foo() -> int;\n  virtual auto bar() -> int;\n};\n\nclass Derived : public Base {\npublic:\n  auto foo() -> int override;  // override\n  auto bar() -> int final;     // final\n};\n\nauto test(Derived* derived) -> int {\n  return derived->foo() + derived->bar();\n}\n```\n\nHere, `foo()`\n\ncan still be overridden, so `derived->foo()`\n\nremains a virtual call. However, `bar()`\n\nis marked as `final`\n\n, so the compiler emits a direct call even though it's declared `virtual`\n\nin the base\n\n```\ntest(Derived*):\n        push    rbx\n        sub     rsp, 16\n        mov     rax, QWORD PTR [rdi]\n        mov     QWORD PTR [rsp+8], rdi\n        call    [QWORD PTR [rax]]       // Virtual call\n        mov     rdi, QWORD PTR [rsp+8]\n        mov     ebx, eax\n        call    Derived::bar()          // Direct call\n        add     rsp, 16\n        add     eax, ebx\n        pop     rbx\n        ret\n```\n\n## Static polymorphism\n\nWhen the compiler can't devirtualize, one option is to use static polymorphism instead. The canonical tool for this is the Curiously Recurring Template Pattern 3 (CRTP). With CRTP, the base class is templated on the derived class, and invokes methods on it via\n\n`static_cast`\n\n---no virtual keyword involved\n\n``` php\ntemplate <typename Derived>\nclass Base {\npublic:\n  auto foo() -> int {\n    return 77 + static_cast<Derived*>(this)->bar();\n  }\n};\n\nclass Derived : public Base<Derived> {\npublic:\n  auto bar() -> int {\n    return 88;\n  }\n};\n\nauto test() -> int {\n  Derived derived;\n  return derived.foo();\n}\n```\n\nWith `-O3`\n\noptimization, the compiler inlines everything and constant-folds the result. No `vtable`\n\n, no `vptr`\n\n, no indirection. Fully optimized 4 call.\n\n```\ntest():\n        mov     eax, 165  // 77 + 88\n        ret\n```\n\n**Deducing this.** C++23's *deducing this* keeps the same static-dispatch model but makes it easier to write. Instead of templating the entire class (and writing `Base<Derived>`\n\neverywhere), you template only the member function that needs access to the derived type, and let the compiler deduce `self`\n\nfrom `*this`\n\n``` php\nclass Base {\npublic:\n  auto foo(this auto&& self) -> int { return 77 + self.bar(); }\n};\n\nclass Derived : public Base {\npublic:\n  auto bar() -> int { return 88; }\n};\n```\n\nThis yields identical optimized code: `foo`\n\nis instantiated as `foo<Derived>`\n\n, and the call to `bar`\n\nis resolved statically and inlined.\n\n-\nAssembly generated with\n\n`gcc`\n\nat`-O3`\n\non x86-64. Similar results were observed with`clang`\n\non the same platform.[↩](#fnref1) -\nThe compiler emits a direct call to\n\n`Derived::foo`\n\n(or inlines it), because`derived`\n\ncannot have any other dynamic type.[↩](#fnref2) -\nThe curiously recurring template pattern is an idiom where a class X derives from a class template instantiated with X itself as a template argument. More generally, this is known as F-bound polymorphism, a form of F-bounded quantification.\n\n[↩](#fnref3) -\nThe trade-off is that each\n\n`Base<Derived>`\n\ninstantiation is a distinct, unrelated type, so there's no common runtime base to upcast to. Any shared functionality that operates across different derived types must itself be templated.[↩](#fnref4)", "url": "https://wpnews.pro/news/devirtualization-and-static-polymorphism", "canonical_source": "https://dev.to/david-alvarez-rosa/devirtualization-and-static-polymorphism-3mmg", "published_at": "2026-05-23 21:36:21+00:00", "updated_at": "2026-05-23 22:01:51.527103+00:00", "lang": "en", "topics": ["developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/devirtualization-and-static-polymorphism", "markdown": "https://wpnews.pro/news/devirtualization-and-static-polymorphism.md", "text": "https://wpnews.pro/news/devirtualization-and-static-polymorphism.txt", "jsonld": "https://wpnews.pro/news/devirtualization-and-static-polymorphism.jsonld"}}