What is Dynamic PGO in .NET, and how does guarded devirtualisation make interface and virtual calls faster?

How I would answer this in an interview

Dynamic PGO (Profile-Guided Optimisation, on by default since .NET 8) lets the JIT observe how your code actually runs — which branches are taken, which concrete types appear at virtual/interface call sites, which delegates are invoked — and then recompile hot methods using that profile. Its flagship optimisation is guarded devirtualisation (GDV): if a call site almost always sees the same type, the JIT emits a cheap type check and a direct, inlinable call for that type, falling back to normal dispatch otherwise.

1. How dynamic PGO works

1. A method starts at Tier 0 (or from ReadyToRun code).
2. When it becomes hot, the runtime compiles an instrumented version that records:
   • block counts (branch frequencies, loop trip counts),
   • class profiles at virtual and interface call sites (which MethodTables are seen),
   • method profiles at delegate call sites,
   • value profiles for some operations (e.g. sizes for memmove/copy in newer versions).
3. After enough executions, the method is recompiled at Tier 1 using that data.

All of this happens automatically at run time, on the real workload — no training runs needed.

2. Guarded devirtualisation

public interface IShippingCalculator { decimal Cost(Order o); }
public sealed class StandardShipping : IShippingCalculator { public decimal Cost(Order o) => o.Weight * 2.5m; }

decimal Total(IShippingCalculator calc, Order o) => o.Subtotal + calc.Cost(o);   // interface call

If the profile shows calc is a StandardShipping 99% of the time, Tier 1 code is roughly:

decimal cost = calc.GetType() == typeof(StandardShipping)        // one pointer compare on the MethodTable
    ? o.Weight * 2.5m                                              // inlined StandardShipping.Cost
    : calc.Cost(o);                                                // fallback: interface dispatch

Benefits:

• No indirect call in the common case (better branch prediction, no stub dispatch).
• Inlining of the target, which unlocks further optimisations (constant folding, removing allocations, loop optimisations).
• Works for virtual calls, interface calls and delegate calls ("delegate GDV"), which is why LINQ predicates and callbacks got faster in .NET 8.
• Can guard multiple likely types (when a site sees two dominant types).

Why it matters: typical .NET code is full of interface calls through DI abstractions (ILogger, repositories, strategies) where each call site usually sees exactly one implementation. GDV recovers most of the cost of those abstractions.

3. Other PGO-driven optimisations

• Hot/cold block layout: frequently executed code placed together; cold paths (error handling) moved out of the way.
• Better inlining decisions based on actual call frequency.
• Loop optimisations informed by trip counts.
• Casting and type-check optimisations using observed types.
• Profile-driven register allocation improvements.

4. Static vs dynamic PGO

NativeAOT can't do dynamic PGO (no JIT), so it relies on static profiles and whole-program analysis — one reason JIT-compiled apps can outperform AOT in steady state.

5. Observing and controlling it

• Default: TieredPGO=true (.NET 8+). Disable with <TieredPGO>false</TieredPGO> or DOTNET_TieredPGO=0 to compare.
• See it in disassembly: DOTNET_JitDisasm="Type:Method" shows guarded checks (cmp ..., MethodTable) and inlined bodies in Tier 1 code.
• Benchmarking: BenchmarkDotNet runs enough iterations for PGO; compare with PGO off to measure impact.
• DOTNET_ReadyToRun=0 can be used to force everything through tiering for experiments.

6. Design implications

• Interfaces with one dominant implementation per call site cost little in steady state.
• Megamorphic sites (many types at one call site, e.g. generic visitor/dispatch loops) don't benefit; consider restructuring hot loops to be monomorphic (process items grouped by type) or using sealed types/generics.
• Sealing classes still helps: the JIT can devirtualise without guards, even before PGO kicks in.
• PGO behaviour depends on the workload; a test environment with different implementations may show different performance.

7. A production example

Upgrading an API from .NET 6 to .NET 8 improved throughput by ~15% without code changes. Profiling showed the gains concentrated in our hot request pipeline: interface calls to IPricingRule, IValidator<T> and LINQ delegates were now guarded-devirtualised and inlined. One endpoint didn't improve — its rule engine looped over 40 different rule types at a single call site (megamorphic). Grouping rules by type and processing each group in its own loop made those sites monomorphic, and PGO then optimised them too.