Static Dispatch (Monomorphization) vs Dynamic Dispatch (dyn Trait VTable)
- Last updated
- Prerequisites:
- Rust traits and generics
- Understanding of dispatch and code generation
- rust
- generics
- monomorphization
- trait-objects
- vtable
- dynamic-dispatch
Read at your depth
The practical view
Generics with trait bounds use static dispatch: fn process<T: Handler>(h: T) — the compiler generates a specialized copy for each concrete type (monomorphization), and calls are direct and inlinable. Trait objects use dynamic dispatch: fn process(h: &dyn Handler) — the value is a fat pointer (data pointer + vtable pointer), and method calls go through the vtable at runtime. Static dispatch is faster (no indirection, inlining possible) but increases binary size; dynamic dispatch is flexible (heterogeneous collections, runtime type choice) with a small per-call cost. Choose generics for hot paths, dyn for collections of mixed types or runtime-selected implementations.
The same idea in other frameworks
N/A — Rust language feature.N/A — Rust feature.N/A — Rust feature.N/A — Rust feature.Legacy vs modern
Generic static dispatch vs dyn Trait object
Generics specialize per type (direct calls, inlining); trait objects go through a vtable (flexible, one indirection per call).
fn sum_all(items: &[&dyn Computable]) -> f64 { // ❌ OLD: vtable call per itemfn sum_all<T: Computable>(items: &[T]) -> f64 { // ✅ NEW: direct callsInterview gotchas
Context
This tests the engineering trade-off — interviewers want code-size/bloat and flexibility considerations, not just the dispatch-speed soundbite.
The mechanical answer
Monomorphization benefits: direct calls (inlinable), no per-call indirection, better constant propagation — and the specialized code can be optimized against the concrete type. Costs: code bloat — each concrete instantiation is a separate copy, so N types × M generic functions can blow up binary size and compile time; this is especially painful with many large generic functions. Trait objects benefit: one copy of the function (smaller binary for heterogeneous use), runtime flexibility (collections of mixed types, plugins, runtime-selected implementations), and stable compile times. Costs: vtable indirection per call (prevents inlining in most cases), fat pointers (2× memory per reference in collections), and the object-safety restriction (no generic methods, no Self-by-value returns). The choice is a real engineering trade-off: hot, type-fixed paths favor generics; polymorphic, mixed-type, or plugin-like boundaries favor dyn.
Trap
The naive answer is 'always use generics, they're faster'. Code bloat and compile-time cost are real; for a small number of instantiations the bloat is minor, but large generic-heavy codebases pay. Another trap: assuming trait objects can express anything generics can — object safety forbids generic methods and by-value Self returns, which is why Box<dyn Clone> doesn't work directly. Candidates who weigh binary size and object safety show real understanding.
Context
This probes the trait-object constraints — interviewers want the rules (no generic methods, no Self by value) and the underlying reason (the vtable can't represent them).
The mechanical answer
A trait is object-safe if it can be dispatched through a vtable. The restrictions: no generic methods (a generic method would need a different vtable entry per type argument, but the vtable is fixed per (trait, concrete type)); no methods returning Self by value (the vtable would need to produce a value of the erased type); no associated constants or functions without a Self argument that would need type information. Also, methods that use Self in certain positions (e.g. fn clone(&self) -> Self) make the trait non-object-safe unless the return is Box<Self>. The vtable stores a fixed set of function pointers; anything that would require knowing the erased concrete type at the call site can't be dispatched dynamically. This is why Clone is not object-safe (returns Self) and why dyn-compatible traits need care.
Trap
The naive answer is 'any trait can be used as dyn Trait'. Object safety forbids generic methods and by-value Self returns. Another trap: thinking Box<dyn Trait> removes the object-safety limits — it only handles the Self-return problem for clone-like cases; generic methods are still not allowed. Candidates who can enumerate the object-safety rules and their vtable rationale show real depth.