.NET JIT Compiler Explained: How Tiered Compilation Works

The JIT doesn't optimize everything equally — it bets on which methods are worth the effort, and it usually bets right.

In the pipeline lesson, you saw that the JIT compiles IL to native code "in tiers." That was intentionally the high-level version. Now let's actually answer the question every curious developer eventually asks: if full optimization produces faster code, why doesn't the JIT just always do that?

The honest answer is that optimization itself isn't free — it costs CPU time to compute. And most methods in a typical program run only a handful of times, ever. Spending heavy optimization effort on a method that runs twice is pure waste; spending it on a method that runs ten million times is enormously profitable. The JIT's whole design is built around figuring out, automatically and cheaply, which methods fall into which category.

In this lesson, you'll go deep on exactly how tiered compilation makes that decision, what Dynamic PGO adds on top of it, and why this design is the right trade-off for the vast majority of real applications.

What Is It?

The Simple Explanation

JIT (Just-In-Time) compilation is the CLR translating IL into native machine code, one method at a time, at the moment each method is first actually called — not before. "Tiered" JIT means the runtime doesn't produce just one version of that native code; it can produce a quick, rough version first, and later replace it with a slower-to-produce, faster-to-run version, but only for methods that prove worth the extra investment.

The Technical Definition

Modern .NET's default JIT strategy has two tiers, on by default since .NET Core 3.0:

The promotion from Tier 0 to Tier 1 happens automatically, on a background thread, once a method's observed call count crosses an internal threshold. This is a runtime implementation detail — the exact number isn't a documented, stable contract — but conceptually: a method called once stays at Tier 0 forever; a method called in a tight loop millions of times gets promoted almost immediately.

Why Does It Exist?

The Problem — a real tension, not a false one

Picture the two extremes a JIT design could pick:

• Always fully optimize, on first call. Every method — including the ones called once during startup and never again — pays the full cost of aggressive optimization before it can run at all. For a large application (think: a big ASP.NET Core service with thousands of methods touched during startup), this can add real, measurable seconds to how long it takes to handle the very first request.
• Never optimize — always produce the fastest-to-generate code. Startup is snappy, but a hot loop that runs for the next six hours of the process's life never gets the benefit of inlining, better register allocation, or loop optimizations — leaving real throughput on the table for the entire remaining lifetime of the process.

Neither extreme is right for a typical long-running server application, which wants both fast startup and excellent sustained throughput.

The Solution — pay for optimization only where it's earned

Tiered compilation resolves the tension by not committing to either extreme up front. Every method gets the cheap version first, so nothing blocks startup. Only methods that actually run often enough to matter get the expensive treatment — and by the time that happens, the runtime has already observed real behavior, which it can use to make even smarter decisions than a purely static, ahead-of-time compiler ever could.

Big Picture

How It Works

Step 1 — First call triggers Tier 0

decimal CalculateDiscount(decimal price, bool isMember)
    => isMember ? price * 0.9m : price;

The first time CalculateDiscount is called, the JIT produces Tier 0 code for it — quickly, without spending effort deciding whether to inline the multiplication or how cleverly to allocate CPU registers. The method runs correctly, just not maximally fast yet.

Step 2 — Call count accumulates

If this method sits behind a checkout endpoint hit thousands of times per minute, its call count climbs quickly. The CLR is counting invocations for exactly this purpose — not for any diagnostic or logging reason.

Step 3 — Threshold crossed → background recompilation

Once the call count crosses the internal threshold, the runtime schedules Tier 1 recompilation of CalculateDiscount on a background thread. Your checkout requests keep being served by the existing Tier 0 code while this happens — there's no pause, no blocking, nothing your code observes directly.

Step 4 — Dynamic PGO uses real observed behavior

Starting in .NET 8, Dynamic Profile-Guided Optimization goes a step further: while a method runs at Tier 0, the JIT can instrument it lightly to record real facts about its execution — for example, which side of a branch is actually taken most of the time, or which concrete type actually flows through a call site that looks polymorphic in the IL. When Tier 1 compilation runs, it uses this real data to make better decisions than a purely static analysis of the IL could — for instance, ordering branches so the common case needs no jump at all, or specializing a virtual call site for the one type that's actually ever seen in practice (with a fallback still in place for the rare case it's wrong).

Step 5 — Tier 1 code takes over silently

Once Tier 1 compilation finishes, the CLR swaps the method's entry point to point at the new native code. Calls already "in flight" using the old code finish normally; new calls from that point forward use the optimized version. From your C# code's perspective, absolutely nothing changed — the method just quietly got faster.

Simple Example

You can see the effect of tiering, indirectly, through timing — though this is illustrative, not a rigorous benchmark:

static long SumOfSquares(int n)
{
    long total = 0;
    for (int i = 0; i < n; i++)
        total += (long)i * i;
    return total;
}

// First call: includes Tier 0 JIT compile time + Tier 0 execution
var sw = Stopwatch.StartNew();
SumOfSquares(50_000_000);
Console.WriteLine($"First call: {sw.ElapsedMilliseconds} ms");

// Later calls, after enough iterations to trigger Tier 1 promotion,
// may run measurably faster per call — same method, same IL, faster native code
sw.Restart();
SumOfSquares(50_000_000);
Console.WriteLine($"Later call: {sw.ElapsedMilliseconds} ms");

What this demonstrates: the first call's time includes both JIT compilation overhead and execution at the less-optimized Tier 0. A later call — assuming enough prior calls occurred to trigger promotion — runs against genuinely different, more optimized native code, even though you didn't change a single line of C#. This is exactly why proper benchmarking tools like BenchmarkDotNet always include a warm-up phase before measuring.

Real-World Example

Two deployment shapes illustrate why this trade-off is tuned automatically rather than being a single fixed choice:

• A long-running order-processing API — deployed once, running for days or weeks, handling millions of requests. Tiered JIT is close to ideal here: startup is fast, and the handful of genuinely hot methods (JSON deserialization, the order-total calculation, a frequently-hit repository method) reach full Tier 1 optimization, with Dynamic PGO further tuning them based on this specific deployment's actual traffic patterns.
• A short-lived Azure Function invoked to resize an uploaded image — the process might handle a single request and then be recycled. Here, most methods never accumulate enough calls to reach Tier 1 at all — the whole invocation runs on Tier 0 code. This is precisely the scenario where teams evaluate ReadyToRun (to skip Tier 0 JIT compile time by shipping pre-JITted code) since Tier 1's benefits are never realized in such a short-lived process anyway.

Analogy

Under the Hood

Common Confusion

1. "Tier 0 means unoptimized garbage code"

Tier 0 code is less optimized than Tier 1, not unoptimized in any absolute sense — it's still correct, still reasonably efficient native machine code, just without the more expensive optimization passes (aggressive inlining, advanced register allocation). For the majority of methods in a typical application — called a handful of times each — Tier 0 code is perfectly adequate and its cost is essentially invisible.

2. "Dynamic PGO is a separate feature you have to turn on"

Dynamic PGO is enabled by default in modern .NET (as of .NET 8) — it's not a separate opt-in optimization mode you configure, but a refinement layered onto the existing tiering pipeline. It's worth knowing it exists mainly so you understand why Tier 1 code can sometimes make surprisingly smart decisions that a plain "recompile with -O3" style optimizer never could — because it's using real, observed runtime behavior, not just static analysis of the IL.

3. "This is basically the same thing as ReadyToRun"

Tiered JIT compilation happens live, at run time, on the machine actually running the app, and it's always adapting based on real observed call counts. ReadyToRun, by contrast, bakes in native code ahead of time, at publish time, before the app has ever run against real traffic — it's a way to skip early Tier-0-equivalent JIT work at startup, not a replacement for the tiering system, which can (and does) still promote hot R2R methods to a fully optimized Tier 1 later, informed by Dynamic PGO.

Common Mistakes

Mistake 1 — Benchmarking without a warm-up phase

Writing a quick Stopwatch-based timing loop and calling the target method only once or twice, then drawing performance conclusions.

Call the method enough times to reach steady state (or use BenchmarkDotNet, which handles this correctly), so you're measuring Tier 1 performance — the number that will actually matter once your app has been running for more than a few seconds.

Mistake 2 — Assuming tiering is something you need to manually configure per method

Hunting for a C# attribute to force a specific method to "skip straight to Tier 1" as routine practice, on the assumption that faster is always better regardless of the method's actual call frequency.

Trust the default heuristics for the overwhelming majority of code — they're tuned against real-world workloads. Advanced knobs for controlling tiering exist for narrow, measured scenarios, not as a first response to a perceived performance problem.

Mistake 3 — Confusing "startup is slow" with "my algorithm is slow"

Profiling a slow startup, seeing time attributed to JIT compilation across hundreds of methods, and concluding your algorithms are inefficient.

Distinguish JIT warm-up cost (compilation time, paid once per method per process) from algorithmic cost (execution time, paid every call). They require completely different fixes — reducing startup-path code for the former, better algorithms or data structures for the latter.

Why Does This Matter for My Code?

Tiered JIT compilation is on by default and self-tuning — there's no "should I use this" decision most teams ever need to make. Where this knowledge pays off is diagnosis and expectation-setting:

• You now know why a load test's first minute of results often looks worse than its later, steady-state results — and that this is expected tiering behavior, not necessarily a red flag.
• You know to warm up code paths before measuring them, and you understand exactly what a benchmarking tool's "warm-up" phase is actually doing under the hood.
• You can reason clearly about when a short-lived process (a CLI tool, a scale-to-zero function) might not benefit much from Tier 1 at all — informing a later, deliberate decision about ReadyToRun or NativeAOT rather than a guess.
• You understand why the same C# code can legitimately run at different speeds at different points in a process's lifetime, without anything in your code changing.

Mental Model

Key Takeaway

Check Your Understanding

You've gone deep on tiered JIT compilation and Dynamic PGO. Let's confirm the mechanics are clear.

You now understand exactly how and why the JIT decides which methods deserve full optimization — and why that decision is made automatically, based on real behavior.