How does interface method dispatch work in the CLR, and why can it be slower than virtual dispatch?

How I would answer this in an interview

With a virtual call, the method's slot index is the same in every derived type, so dispatch is a fixed vtable lookup. With an interface call, that's impossible: a class can implement many interfaces in any order, and unrelated classes implement the same interface at different slot positions. CoreCLR therefore uses virtual stub dispatch (VSD): each interface call site goes through a small stub that caches the target for the types it sees. Monomorphic sites end up almost as fast as virtual calls; polymorphic/megamorphic sites need hash-table lookups and are slower.

1. Why interfaces can't use fixed slots

class A : IShippable, IAuditable { ... }   // IShippable methods might be slots 4-5
class B : IAuditable, IShippable { ... }   // here they might be slots 6-7
class C : Base, IShippable { ... }          // different again

The caller only knows "call IShippable.Ship on this object" — it doesn't know where Ship lives in that object's vtable. The runtime must map (object's type, interface method) → implementation, using the type's interface map.

2. Virtual stub dispatch

Each interface call site calls through an indirection cell that initially points to a lookup stub:

1. Lookup stub (first call): calls into the runtime to resolve the target for the object's type (walking the interface map), then patches the cell.

2. Dispatch stub (monomorphic): compares the object's MethodTable with the cached type; if equal, jumps directly to the cached target; else falls to the resolve path.

   mov  rax, [rcx]                  ; object's MethodTable
   cmp  rax, [cached_MT]
   jne  RESOLVE
   jmp  [cached_target]
   

3. Resolve stub (polymorphic): if a site keeps missing (several types), the cell is backpatched to a resolve stub that looks up (MT, interface method) in a global hash cache, falling back to the runtime on a miss.

Stubs are shared per interface method and the cache adapts over time. (NativeAOT uses a similar "cached interface dispatch" approach with per-call-site caches.)

3. Why it can be slower than virtual dispatch

Plus the shared cost with virtual calls: no inlining unless devirtualised.

Additional costs:

• Structs via interfaces: calling an interface method on a struct through an interface reference requires boxing.
• Default interface methods add resolution complexity (most specific implementation).
• Generic interfaces with variance can need extra checks during casting.

4. How the JIT avoids the cost

• Devirtualisation when the concrete type is known (sealed classes, new in the same method).
• Guarded devirtualisation via dynamic PGO: if (obj.MT == StripeGateway_MT) { inlined call } else { stub call } — very effective because most DI-injected interfaces have exactly one implementation per call site.
• Generic constraints with value types: void Process<T>(T x) where T : IShippable with a struct T compiles to a direct call (constrained call), no stubs, no boxing.

5. Practical guidance

• For normal application code (DI services, repositories), interface dispatch overhead is negligible — and PGO removes most of it.
• For hot inner loops over interface-typed elements:
  • make sites monomorphic (group by type),
  • seal implementations,
  • use generic methods constrained to the interface with struct implementations,
  • or restructure to operate on concrete types/spans.
• Avoid passing structs as interfaces in hot paths (boxing).

6. A production example

A telemetry pipeline processed millions of events per second through IEnumerable<IEventEnricher> with ~15 enricher implementations per event, invoked at one call site — megamorphic interface dispatch in the hottest loop. Profiles showed resolve-stub overhead and no inlining. We changed the pipeline to a generic EnricherPipeline<TEnricher1, TEnricher2, ...>-style composition for the fixed core enrichers (struct implementations, constrained calls), keeping the interface-based extension point for rare custom enrichers. Throughput improved ~35%.