Learn .NET - Performance & Diagnostics

#Introduction

A correct application is not necessarily a fast one. Episode 15 covers performance and diagnostics: how to measure application behavior with data, find bottlenecks, and apply the right optimization techniques. The main rule: measure first, optimize afterwards.

You will get to know the official .NET profiling tools, analyze memory allocations, learn about Span<T> for minimal-allocation code, and understand hot reload, tiered compilation, and when AOT is worth using. Optimization without measurement is just guessing.

#Profiling with dotnet-trace and dotnet-counters

#Installing the Diagnostic Tools

The .NET diagnostic tools are installed as global tools:

dotnet tool install --global dotnet-trace
dotnet tool install --global dotnet-counters
dotnet tool install --global dotnet-dump

dotnet-trace, dotnet-counters, and dotnet-dump are the main diagnostic trio. dotnet-counters monitors metrics in real time; dotnet-trace collects traces that can be analyzed in depth.

#Monitoring Real-Time Metrics

Run your application and observe CPU, GC, and memory metrics:

dotnet-counters monitor --process-id 12345

dotnet-counters monitor --process-id 12345 displays metrics such as cpu-usage, working-set, and the number of allocations per second. This screen immediately shows whether the application is busy with GC or allocating memory abnormally.

#Collecting Traces

For deep investigation, collect a trace:

dotnet-trace collect --process-id 12345 --profile gc-verbose

dotnet-trace collect --profile gc-verbose records GC and allocation activity to a trace file. This file can be opened with dotnet-trace report or tools like PerfView to find the most-allocated objects.

#Memory Diagnostics and GC Tuning

#Understanding GC Pressure

GC works automatically, but it can still be optimized. Key metrics:

• Allocation Rate: how fast memory is allocated.
• GC Count: how often GC runs.
• GC Time: the proportion of time spent on GC.

The main tuning is reducing unnecessary allocations. Among other things, by using collections with initial capacity, avoiding closures that capture large state, and using ArrayPool for temporary buffers. Avoid setting GC aggressively without data — in most cases, reducing allocations is more effective than changing the GC mode.

#Span and Memory for Minimal Allocations

#Span for Stack Data

Span<T> represents a region of memory that can be accessed without heap allocation:

Span<int> angka = stackalloc int[] { 1, 2, 3, 4, 5 };
 
foreach (ref var n in angka)
{
    n *= 2;
}

stackalloc allocates the array on the stack — no GC pressure at all. Span<T> works on contiguous memory and is the basis of optimizations such as high-performance parsing and serialization.

#Memory for Long-Lived Data

Memory<T> is the version of Span<T> that is safe for data living beyond the method (for example, stored in a Task). The practical rule: use Span<T> for short local operations, and Memory<T> when data must be stored or passed to another method. Both avoid unnecessary data copies.

#Hot Reload, Tiered Compilation, and AOT

#Hot Reload for Fast Iteration

Hot reload lets you apply code changes without a restart. Run it with:

dotnet watch run

dotnet watch run watches source files and applies changes live. In production this feature is not used — but during development, it drastically cuts iteration time.

#Tiered Compilation

Tiered compilation is enabled by default: methods run quickly with lightweight JIT (tier 0), then get optimized more aggressively once they prove hot (tier 1). The result is fast startup and high steady-state performance. For workloads that need the fastest possible startup, consider disabling tiering or using AOT.

#When to Use AOT

NativeAOT compiles the entire application to native code at publish time:

dotnet publish -c Release -r linux-x64 -p:PublishAot=true

dotnet publish -c Release -r linux-x64 -p:PublishAot=true produces a native binary with no separate runtime. The benefits are instant startup and a small footprint — ideal for serverless and edge. The limitations: reflection is restricted and adaptive JIT performance is unavailable, so AOT is not for every workload.

#Performance Practice Summary

• Profile regularly with dotnet-counters and dotnet-trace.
• Reduce allocations: collections with capacity, ArrayPool, avoid closures.
• Use Span for local buffers; Memory for long-lived data.
• Take advantage of hot reload for fast iteration during development.
• Evaluate AOT for critical startup and resource-constrained environments.

#Closing

Key takeaways:

• Measure with dotnet-counters and dotnet-trace before optimizing.
• Allocation rate and GC time are key memory pressure metrics.
• Reducing allocations is more effective than changing the GC mode.
• Span<T> accesses memory without allocation; stackalloc for the stack.
• Hot reload speeds up iteration; tiered compilation balances startup and performance.
• AOT gives instant startup with reflection limitations.

In the next episode 16 we will discuss advanced architecture and patterns — clean architecture, layered architecture, and the modular monolith, mediator and event-driven design, CQRS and domain-driven design, and service composition and bounded contexts.