Below is a deep technical review of memory management and runtime performance in .NET, focused on how it actually behaves internally and how a senior engineer should reason about it.

Memory management and runtime performance in .NET

Internals and behavior

PART 1 — CORE CONCEPTS RECAP

Stack vs heap

At a high level, the stack is for call-local execution state, while the heap is for dynamically allocated objects whose lifetime is not tied to a single method call.

Stack

The stack is typically used for:

method frames
parameters
local variables
return addresses
temporary bookkeeping for execution

Important nuance: saying “value types live on the stack” is not always true.

A value type can live:

on the stack, if it is a local and not lifted/embedded elsewhere
inside an object on the heap, if it is a field of a reference type
inside an array, if it is an element of a value-type array
in registers, if the JIT optimizes it that way
sometimes effectively “not materialized” in memory as you imagine, due to JIT optimization

So the real rule is:

stack is about storage tied to execution frames
heap is about object lifetime managed independently of a single frame

Heap

The managed heap stores most reference-type objects and some runtime structures. Heap allocation is fast in the common case because .NET generally allocates by moving a pointer forward in a region of memory, not by searching for a hole like a traditional malloc-style allocator.

But “heap allocation is fast” does not mean “heap allocation is free.”

The real cost often comes later:

GC work
promotion
cache effects
fragmentation
pause time
retained memory growth

Value types vs reference types

Reference types

Reference types include:

class
string
array
delegate
most framework objects

A variable of reference type usually holds a reference to an object on the managed heap.

That means:

assignment copies the reference, not the whole object
multiple references can point to the same object
lifetime is controlled by reachability and GC

Value types

Value types include:

struct
primitive numerics like int, double
bool
user-defined structs
enums

A value-type variable conceptually contains the data itself.

That means:

assignment copies the value
no independent object identity by default
can avoid heap allocation in many cases

But value types are not automatically “faster.” Large structs can hurt performance because copying them is expensive. Badly designed mutable structs can also create correctness problems.

Managed memory model in .NET

The .NET runtime gives you managed memory, meaning:

you allocate objects without manually freeing them
the GC reclaims unreachable objects
the runtime tracks object references
memory safety is much stronger than in unmanaged systems

But “managed” does not mean “no memory problems.” It means a different class of problems.

Instead of manual free bugs, you get:

allocation churn
GC pauses
accidental retention
LOH pressure
fragmentation
event-based leaks
cache-unfriendly object graphs

The key mental shift is:

In .NET, performance problems often come less from individual allocations and more from allocation patterns and lifetime patterns.

PART 2 — GARBAGE COLLECTOR INTERNALS

Generational GC

.NET uses a generational garbage collector based on a very practical observation:

Most objects die young.

So instead of scanning the whole heap every time, the runtime splits managed objects into generations:

Gen 0: newest objects
Gen 1: middle generation, acts as a buffer
Gen 2: long-lived objects

This makes collection more efficient because short-lived garbage can often be reclaimed cheaply.

Gen 0 / Gen 1 / Gen 2

Gen 0

This is where most small new objects begin life.

Examples:

temporary strings
enumerators
short-lived DTOs
lambda capture objects
short-lived lists
per-frame calculation objects

A Gen 0 collection happens frequently. It is usually fast because:

Gen 0 is small
many objects there are already dead
the GC only needs to inspect a relatively small region

Gen 1

Gen 1 is a transitional generation.

It exists to avoid promoting everything straight from Gen 0 to Gen 2. Think of it as a shock absorber between young and old objects.

Gen 2

Gen 2 contains long-lived objects.

Examples:

application-wide caches
static object graphs
long-lived view models
retained images
big collections used across many screens
background service instances

Gen 2 collections are more expensive because the collector must consider much more memory and much more object graph connectivity.

Ephemeral segment

Gen 0 and Gen 1 live in the ephemeral segment.

This is the region optimized for short-lived allocations and frequent young-generation collections. When people say .NET is very good at handling short-lived garbage, this is one major reason why.

The GC is built around the idea that young allocations are common and reclamation should be efficient.

What a collection cycle really does

At a high level, a GC cycle does roughly this:

Pause managed execution enough to establish a safe point
Find roots
- stack references
- CPU registers
- statics
- GC handles
- finalizer-related roots
Mark reachable objects
- anything reachable from roots is considered alive
Identify unreachable objects
- these are garbage
Reclaim memory
For compacting generations, move surviving objects to reduce fragmentation
Update references to moved objects
Resume execution

That is the high-level picture. Internally, the actual implementation is more sophisticated and may overlap some work concurrently depending on GC mode, but this is the mental model that matters.

Stop-the-world concept at a high level

“Stop-the-world” means managed threads are paused so the GC can safely reason about object references.

Why pause? Because if threads kept changing object graphs while the GC was walking them, the collector could not reliably know what is alive.

In modern .NET, not all GC work is always done in one giant pause. Some phases can be concurrent or background. But from the app’s point of view, GC still introduces pause effects, and those pauses matter a lot in:

UI responsiveness
real-time-ish desktop screens
high-frequency streaming
latency-sensitive interaction loops

A senior engineer should never think: “GC is automatic, so pause behavior is irrelevant.”

PART 3 — LARGE OBJECT HEAP (LOH)

What goes to the LOH

Large objects are allocated on the Large Object Heap when they are above a threshold, historically around 85,000 bytes of payload.

Typical LOH objects:

large arrays
large strings
big image buffers
large byte arrays from I/O
large object graphs wrapped around large arrays

In real systems, the most common LOH offenders are usually arrays:

byte[]
int[]
double[]
pixel buffers
decoded image buffers

Why large object allocations are expensive

Large allocations are expensive for several reasons:

More memory to reserve and track
They tend to be longer-lived
They can create fragmentation
They often lead to Gen 2 pressure
Zeroing large memory blocks has real CPU cost
They stress cache and memory bandwidth

The cost is not just “allocation time.” The bigger problem is what these objects do to overall heap health and GC behavior.

Fragmentation concerns

Small-object generations are often compacted, which helps keep memory dense.

The LOH historically was not compacted by default as aggressively as smaller generations. That means if large objects are allocated and freed in varying sizes, you can end up with holes between live objects.

So you may see:

lots of free memory in theory
but not enough contiguous free space for the next large allocation
more segment growth
rising memory footprint
more expensive full collections

This is classic fragmentation behavior.

Why image-heavy systems often hit LOH issues

Image-heavy systems are a perfect storm:

image buffers are large
decoded bitmaps are much larger than compressed files
thumbnails can still be surprisingly large
resizing or conversion often creates additional temporary buffers
many pipelines duplicate data unintentionally

For example, a compressed image file on disk may be a few MB, but once decoded into raw pixel memory it can become tens of MB. If you keep original, resized, display-ready, and processed versions around at the same time, memory explodes.

This is why inspection systems, medical imaging viewers, vision systems, and WPF apps dealing with many bitmaps often get LOH pressure fast.

PART 4 — ALLOCATION PATTERNS

Short-lived vs long-lived allocations

This matters more than people think.

Short-lived allocations

These are objects created and discarded quickly.

Examples:

temporary parsing objects
loop-local projections
short-lived tasks
LINQ intermediate objects
transient string formatting results

Short-lived allocations are usually okay if the rate is reasonable, because Gen 0 is optimized for them.

Long-lived allocations

These survive collections and get promoted.

Examples:

retained caches
long-lived UI object graphs
event subscriptions
persistent view models
image buffers kept in memory
static dictionaries with growing content

These are more dangerous because they move toward Gen 2, where GC becomes more expensive.

Allocation rate

Allocation rate is one of the most important runtime performance concepts.

It is not just “how much memory do I use.” It is:

How fast am I creating new managed objects?

A program with modest steady-state memory but enormous allocation churn can still perform badly because it forces constant GC activity.

Example:

app only uses 400 MB steady-state
but allocates several GB per minute transiently

That app can still be very GC-heavy and sluggish.

Promotion between generations

Objects start young. If they survive a collection, they may be promoted:

Gen 0 survivors may move to Gen 1
Gen 1 survivors may move to Gen 2

Promotion is not good news. Promotion means:

the object stayed alive longer than expected
future collections involving that object may be more expensive
the GC must now consider it in older generations

A useful rule of thumb:

Temporary objects are usually fine. Accidentally retained temporary objects are expensive.

Why high allocation frequency hurts performance

High allocation frequency hurts because it increases:

GC frequency
memory bandwidth pressure
cache churn
root scanning work
object promotion risk

And in UI apps, high allocation rate often creates a “soft stutter” pattern:

not a total freeze
but frequent tiny pauses
frame drops
laggy scrolling
delayed user interaction

That is often harder to diagnose than a crash.

PART 5 — MEMORY PRESSURE & GC IMPACT

How memory pressure triggers collections

GC does not simply run at a fixed interval. It is driven by allocation behavior and memory pressure heuristics.

At a high level, the runtime tracks:

how much has been allocated
how full generations are becoming
survival rates
heap growth patterns
system memory conditions

When thresholds are crossed, collections happen.

Important point: the trigger is not just “out of memory.” GC runs much earlier, trying to keep memory healthy and reduce future pain.

How GC pauses affect UI responsiveness

In a WPF app, the UI thread is precious. If GC pauses coincide with:

rendering work
data binding bursts
list updates
image decode/display operations

the user experiences:

frozen interaction
stuttering animation
delayed button response
laggy scroll/zoom
intermittent hangs

Even short pauses matter if they happen at the wrong time.

For UI, latency matters more than average throughput. A system that is “fast on average” but occasionally pauses for 100–300 ms feels worse than one with slightly lower throughput but more stable latency.

How long-running apps accumulate performance problems

Long-running apps suffer in ways short-lived request/response apps often do not.

Common patterns:

small leaks accumulate into large retained graphs
stale caches grow slowly
event subscriptions keep dead screens alive
image buffers remain referenced after navigation
Gen 2 gets crowded with “should-have-died” objects
fragmentation worsens over hours or days
background pipelines keep producing garbage indefinitely

This is why a desktop app can start fast in the morning and become sluggish by afternoon without any obvious bug at a single line of code.

The problem is often not one catastrophic allocation. It is thousands of reasonable-looking allocations and retained references interacting over time.

PART 6 — WPF + MEMORY / PERFORMANCE

Object graph size in UI apps

WPF apps can build very deep and wide object graphs.

One visible screen may involve:

Window
visual tree
logical tree
controls
templates
styles
bindings
converters
commands
view models
collections
images
validation objects
event subscriptions

So “one screen” is often actually hundreds or thousands of objects.

This matters because GC cost is strongly influenced by:

object count
graph connectivity
retention
generation age

A UI issue is often really an object graph issue.

Bindings are convenient, but not free.

Binding-related costs can include:

BindingExpression objects
change notification plumbing
boxing in some paths
converter allocations
formatted string creation
temporary collection views
delegate and closure allocations
per-item container creation in large item controls

One binding is cheap. Ten thousand dynamic bindings updating frequently are not.

Image sources / bitmap memory concerns

WPF image handling is one of the easiest places to get into trouble.

Common problems:

loading full-resolution images when thumbnails would do
keeping original and rendered versions both alive
repeated image conversions
unmanaged/native backing memory hidden behind managed wrappers
delayed release because references remain in UI trees or caches
decode on UI thread causing visible stalls

A dangerous misconception is: “The managed wrapper is small, so memory cost is small.” Not true. Bitmap-related types often hide large native memory underneath.

So you need to think about both:

managed heap pressure
unmanaged/native memory footprint

Large collections and virtualization impact

Showing large collections in WPF can be very expensive if virtualization is not working.

Without effective virtualization, the UI may create:

container objects for every item
visual elements for every row
bindings for every field
templates for every element

That explodes:

memory usage
layout cost
render cost
GC churn

Virtualization helps by creating UI elements only for visible items plus a small buffer.

But virtualization can be accidentally disabled by:

wrong panel choices
grouping/sorting patterns
nested scroll viewers
custom templates
certain layout behaviors

In real systems, many “WPF is slow” complaints are actually “virtualization is broken.”

PART 7 — PERFORMANCE MEASUREMENT

Throughput vs latency

These are not the same.

Throughput

How much total work gets done over time.

Examples:

images processed per minute
records streamed per second
defects classified per batch

Latency

How long one operation takes, especially worst-case or percentile behavior.

Examples:

time from machine event to UI update
time to open image viewer
pause duration during scrolling
button response delay

In desktop systems, latency spikes are often more visible to users than lower average throughput.

Allocation profiling

Allocation profiling answers:

what types are being allocated
how much is being allocated
where allocations come from
which hot paths create the most garbage

This is critical because many performance problems are allocation-driven, not CPU-driven.

Useful mindset:

total memory size tells you retained state
allocation profiling tells you churn

You need both.

CPU profiling vs memory profiling

CPU profiling

Use when the app is busy and consuming CPU. It answers:

where time is spent
which methods dominate execution
whether rendering, parsing, or algorithmic work is the bottleneck

Memory profiling

Use when the app:

grows in memory
gets slower over time
pauses due to GC
behaves fine at start but degrades later

It answers:

what is still alive
why it is still alive
which references are keeping it alive
what allocation paths are hottest

A senior engineer must know that CPU and memory problems often masquerade as each other.

Example: A method may look CPU-heavy, but the real issue is that it allocates massive temporary objects, which then trigger GC, and the user perceives “slow CPU.”

What metrics matter in production

The most useful production metrics usually include:

allocation rate
GC count by generation
time spent in GC
pause duration trends
working set / private bytes
managed heap size
LOH size
Gen 2 growth
exception rate
UI latency / frame hitching
queue sizes in streaming pipelines

For desktop systems, I would especially care about:

whether memory returns to baseline after heavy workflows
whether Gen 2 steadily grows over hours
whether UI pause patterns correlate with image operations or bulk updates

PART 8 — COMMON LOW-LEVEL PITFALLS

Boxing allocations

Boxing happens when a value type is wrapped as an object or interface reference.

Examples:

passing int where object is expected
using non-generic APIs
some interface calls on structs
string formatting or logging patterns in certain cases

Why it hurts:

hidden heap allocation
extra copying
extra GC pressure
can be disastrous in tight loops

One boxed value is irrelevant. Millions in a hot path are not.

Closure allocations

Closures happen when lambdas capture variables from outer scope.

That often creates a compiler-generated object to hold captured state.

Example patterns:

LINQ in hot loops
event handlers capturing this
async continuations capturing local state
deferred delegates created per item

Why it hurts:

invisible allocations
extra retained references
sometimes keeps larger object graphs alive than intended

A classic bug is not just allocation cost, but retention: a closure capturing this can keep an entire screen or service graph alive.

String-heavy hot paths

Strings are immutable, which is great for safety, but bad for churn in hot paths.

Common problems:

repeated concatenation
formatting in loops
building log messages that are never needed
parsing with too many substring copies
converting numbers to strings too often for display

In telemetry-heavy or UI-heavy systems, string churn can become a major Gen 0 source.

Unnecessary LINQ allocations

LINQ is elegant, but in hot paths it can create:

enumerators
iterator objects
closures
intermediate collections
projection objects

The issue is not “never use LINQ.” The issue is:

Do not use allocation-heavy abstractions blindly in code that runs per frame, per pixel, per event, or per item across very large sets.

Event-handler memory leaks

This is one of the most common managed-memory leaks.

Pattern:

long-lived publisher
short-lived subscriber
subscriber registers event handler
subscriber should die but cannot, because publisher still references delegate
subscriber stays alive forever

In desktop apps, this often leaks:

windows
dialogs
view models
controllers
monitoring panels

This is a true memory leak in managed code: not because memory is “lost,” but because objects remain reachable unintentionally.

Keeping references alive accidentally

This is the most important category.

Examples:

static caches
singleton dictionaries
background tasks holding delegates
closures capturing large objects
collections not cleared on navigation
command handlers retaining screen state
image cache with no eviction policy
diagnostics history lists growing forever

The GC only frees unreachable objects. If you accidentally keep a reference, the GC is doing exactly what you told it to do.

PART 9 — ADVANCED OPTIMIZATION CONCEPTS

ArrayPool

ArrayPool<T> is a shared pool for reusing arrays instead of allocating new ones repeatedly.

Why it helps:

reduces allocation churn
avoids repeated LOH allocations for large buffers
lowers GC pressure
useful for high-throughput pipelines, serialization, parsing, imaging

Trade-offs:

arrays may be larger than requested
contents may contain old data unless cleared
misuse can cause correctness bugs
returning arrays incorrectly can be dangerous

It is most justified when:

buffers are repeatedly allocated in hot paths
object lifetime is short and predictable
profiling shows arrays dominate allocation pressure

`Span<T>` / `Memory<T>` at a high level

Span<T> lets you work with contiguous memory slices efficiently, often without extra allocation.

Think of it as a view over memory rather than a new allocated container.

Why it matters:

avoids substring/subarray copying in many cases
improves locality
enables lower-allocation parsing and transformation pipelines

Span<T> is stack-only and has safety restrictions by design. Memory<T> is the more flexible heap-friendly companion when async or broader lifetime is needed.

These APIs are powerful, but not magic. They are most useful when profiling shows:

too many buffer copies
too many temporary substrings
parser/serializer hot paths
tight byte-processing loops

Pooling and reuse

Pooling is a broader strategy:

object pools
buffer pools
reusable builders
retained working buffers
preallocated pipeline state

It can reduce GC cost dramatically in the right scenario.

But pooling also adds complexity:

harder ownership rules
risk of stale state bugs
accidental cross-thread reuse
memory retained longer than necessary
harder debugging

Poor pooling can make the app worse, not better.

When these optimizations are justified

They are justified when all of these are true:

the path is actually hot
profiling shows allocation or copy cost is material
simpler fixes are insufficient
the team can maintain the added complexity

Do not introduce low-level optimization as decoration.

PART 10 — SENIOR ENGINEER MENTAL MODEL

How to reason about allocations and object lifetime

A strong mental model is:

1. Ask what gets allocated

Not just the obvious object. Also ask:

hidden iterators?
closures?
boxing?
temporary strings?
buffers?
wrappers around native resources?

2. Ask how often

Frequency often matters more than size.

A tiny allocation in a million-iteration loop is more dangerous than a moderate allocation on a rare path.

3. Ask how long it lives

Does it die immediately, or survive long enough to promote?

4. Ask who still references it

This is the leak question.

5. Ask whether the cost is CPU, memory, or latency

The user often only says “it feels slow.” You need to distinguish:

pure compute bottleneck
allocation churn
GC pause problem
rendering/layout issue
native memory growth
lock contention disguised as slowness

How to identify real bottlenecks before optimizing

A senior engineer should work in this order:

define the symptom precisely
reproduce it under representative load
measure before changing code
separate steady-state memory from allocation churn
separate CPU cost from GC cost
inspect retention paths for growth issues
optimize the dominating cause, not the most visible code

Common failure mode: engineers optimize a method because it looks ugly, while the real bottleneck is a retained image cache or broken virtualization.

How to balance code clarity vs performance

The right rule is:

Start clear. Measure. Optimize where it matters. Keep the optimized boundary small.

Good senior judgment looks like this:

use normal clean code for non-hot paths
use simpler high-level APIs where cost is negligible
reserve low-level techniques for measured hotspots
isolate tricky performance code behind well-named components
document why an optimization exists

You do not want an entire codebase written like a hand-tuned parser just because one screen had a GC issue.

A practical approach:

1. Decide whether the problem is:

true retention growth
transient spikes
LOH fragmentation
native memory growth
allocation churn causing frequent GC

2. Observe trends

Look at:

managed heap over time
Gen 2 growth
LOH growth
GC frequency
pause patterns
working set after workload ends

3. Take snapshots

Compare before and after:

open screen
process workload
navigate away
force normal idle period
see what remains

4. Find retention paths

Ask:

why is this object still rooted?
static?
event handler?
cache?
task?
command?
UI tree?
closure?

5. Fix lifetime ownership first

Usually the best fix is not “reduce allocations.” It is:

release references correctly
dispose correctly
unsubscribe correctly
bound caches
avoid duplicate buffers
reduce object graph retention

6. Optimize churn only after retention is understood

Because a leaking system with lower allocation rate is still a leaking system.

Final senior-level summary

The most important thing to internalize is this:

.NET memory performance is mostly about lifetime behavior, allocation rate, and retention shape.

Not just “heap vs stack.” Not just “GC is automatic.” Not just “avoid allocations.”

A senior engineer should think in terms of:

what is allocated
how often it is allocated
how long it survives
what keeps it alive
which generation it pressures
whether the user feels the impact as throughput loss, latency spikes, or memory growth

In real production systems, especially desktop and image-heavy systems, the biggest wins usually come from:

controlling object lifetime
preventing accidental retention
reducing large-buffer churn
fixing UI virtualization and data-flow design
measuring before optimizing
optimizing the right boundary, not just the ugliest code

If you want, I can turn this into a Part 2 interview Q&A pack with deep technical questions and model answers for Principal/Senior .NET interview preparation.

Let’s go deep into memory leak cases in .NET, but from a runtime + production perspective, not just definitions.

Memory leaks in .NET

What they really are

First, reset the mental model:

In .NET, a memory leak is NOT “forgot to free memory.” It is: objects that are still reachable but should not be alive anymore.

The GC is doing its job correctly — your object graph is wrong.

1. THE CORE PROBLEM: UNINTENDED OBJECT RETENTION

A memory leak always comes down to this:

GC Roots → ... → Object (should be dead but still referenced)

GC roots include:

static fields
thread stacks
CPU registers
GC handles
finalizer queue
active tasks / async state machines

If your object is reachable from any of these → it stays alive.

2. MOST COMMON REAL-WORLD LEAK CASES

CASE 1 — EVENT HANDLER LEAK (THE #1 CLASSIC)

Scenario

csharp

publisher.SomeEvent += subscriber.Handle;

If:

publisher is long-lived (singleton, service, static)
subscriber is short-lived (ViewModel, screen)

Then:

publisher → delegate → subscriber

So subscriber never dies.

Real WPF example

MainWindow (long-lived)
Child ViewModel subscribes to global event bus

User closes screen → ViewModel should be GC’ed → but it stays forever

Why it’s dangerous

leaks accumulate slowly
no crash, just growing memory
hard to notice until hours later

Fix patterns

csharp

publisher.SomeEvent -= subscriber.Handle;

or use:

weak events (WeakEventManager)
event aggregator with weak references
lifecycle-aware subscriptions

CASE 2 — STATIC / SINGLETON HOLDING REFERENCES

Scenario

csharp

public static List<ViewModel> Cache = new();

csharp

Singleton.Instance.Store(viewModel);

What happens

Static = GC root

static → ViewModel → UI → images → large graph

Nothing inside can be collected.

Real production example

caching inspection results
storing UI state globally
logging history lists that never clear

Fix

bounded cache (size limit, LRU)
clear on navigation
avoid storing UI objects in static scope

CASE 3 — CLOSURE CAPTURE LEAK

Scenario

csharp

button.Click += (s, e) => DoSomething(this);

or:

csharp

Task.Run(() => Process(this.largeObject));

What happens

Compiler creates hidden class:

closure → this → entire object graph

Even worse:

async/Task prolongs lifetime
background queue holds reference

Real example

background processing queue capturing ViewModel
delayed tasks holding UI state
timers capturing screen objects

Fix

avoid capturing this
extract only needed data
use weak references if needed
cancel tasks when screen is disposed

CASE 4 — TASK / ASYNC NEVER COMPLETES

Scenario

csharp

await Task.Delay(-1); // or never-ending task

or:

Task stored in static list
long-running background loop

What happens

Async state machine holds:

Task → state machine → captured variables → object graph

If task never completes → objects never released

Real example

polling loops
message listeners
machine monitoring threads

Fix

use CancellationToken
ensure tasks complete or cancel
don’t store tasks unnecessarily

CASE 5 — COLLECTIONS THAT KEEP GROWING

Scenario

csharp

_list.Add(item);

but never removed

Real example

log history
telemetry buffer
UI data list
inspection results
image history

What happens

List → all items ever added

Even if UI no longer needs them

Fix

cap size (ring buffer)
clear periodically
stream instead of accumulate

CASE 6 — WPF VISUAL TREE NOT RELEASED

Scenario

navigating between screens
controls removed from UI
but references still exist

Common causes

event handlers
bindings referencing parent
commands referencing ViewModel
static resource references
DataContext not cleared

What happens

Window → VisualTree → Binding → ViewModel → data → images

Even after closing screen

Real symptom

memory increases after each navigation
never returns to baseline

Fix

clear DataContext
unsubscribe events
break references on unload
use weak patterns

CASE 7 — IMAGE / BITMAP MEMORY LEAK

Scenario

load images repeatedly
convert formats
cache without eviction

Important nuance

Many image types use native memory under the hood.

So:

managed object small
native memory huge

What happens

GC sees small object
native memory still large
memory usage explodes

Real example

inspection images
thumbnails + full images both kept
repeated decoding

Fix

dispose correctly (if required)
reuse buffers
avoid duplicate images
downscale early
implement cache eviction

CASE 8 — UNMANAGED RESOURCE LEAK

Scenario

Using:

file handles
sockets
bitmaps
streams

Without disposing

Example

csharp

var stream = new FileStream(...);
// forgot Dispose()

What happens

GC eventually cleans managed object
BUT unmanaged resource stays until finalizer
finalizer runs late → resource pressure builds

Fix

using / Dispose
avoid finalizer reliance
implement IDisposable correctly

CASE 9 — FINALIZER QUEUE BACKLOG

Scenario

Objects with finalizers:

csharp

~MyClass() { ... }

What happens

object survives at least 1 GC
goes to finalizer queue
processed later by finalizer thread

If many:

queue backlog
memory grows
GC pressure increases

Fix

avoid finalizers unless necessary
use SafeHandle pattern
dispose explicitly

CASE 10 — LOH RETENTION (NOT TRUE LEAK BUT LOOKS LIKE ONE)

Scenario

allocate large arrays/images
release them
memory not returned to OS

What happens

LOH not compacted aggressively
memory fragmented
process memory stays high

Symptom

memory usage high even after freeing objects

Important insight

This is often not a leak, but:

fragmentation
heap expansion behavior

Fix

reuse large buffers
avoid frequent large allocations
pooling (ArrayPool)

3. HOW TO DETECT MEMORY LEAKS (REAL APPROACH)

Step 1 — Observe pattern

Ask:

does memory grow over time?
does it drop after workload ends?
does it grow per screen navigation?

Step 2 — Reproduce scenario

Example:

open screen
close screen
repeat 10 times

If memory increases each time → leak

Step 3 — Compare snapshots

Look for:

objects increasing count
objects that should be gone but remain

Step 4 — Find retention path

The most important question:

“What is holding this object alive?”

Trace:

GC Root → ... → Leaked Object

Common roots:

static
event
task
closure
collection

4. SENIOR ENGINEER MENTAL MODEL

Rule 1 — GC only collects unreachable objects

So always ask:

Who is still referencing this?

Rule 2 — Leaks are graph problems, not allocation problems

Bad thinking:

“We allocate too much”

Correct thinking:

“We retain what we shouldn’t”

Rule 3 — UI systems leak easily

Because:

long-lived roots (App, Window, services)
complex graphs
events everywhere
bindings everywhere
async everywhere

Rule 4 — Most leaks are slow leaks

not obvious
accumulate over time
appear after hours/days

Rule 5 — Fix ownership, not symptoms

Bad fix:

forcing GC
clearing random objects
micro-optimizing allocations

Correct fix:

remove root reference
fix lifecycle
unsubscribe / dispose properly

FINAL SUMMARY

Most real .NET memory leaks come from:

Event subscriptions not removed
Static/singleton references
Closures capturing large objects
Long-running tasks holding state
Collections growing forever
UI trees not released (WPF)
Image/native memory misuse
Missing Dispose on unmanaged resources

If you want, next I can give:

👉 “Real debugging walkthrough: find a leak step-by-step (with dotMemory / PerfView mindset)”

This is extremely useful for interviews and real production incidents.

Good idea. The right way to really understand memory leaks is to go one leak pattern at a time, and for each one first explain the basic language/runtime concept, then show how the leak happens, then show how to think about fixing it.

I’ll start with the most important one.

1. Event handler leak

First understand: delegate and event

Before talking about the leak, we need to understand what a delegate is.

What is a delegate?

A delegate in .NET is an object that represents a method call.

For example:

csharp

public void PrintHello()
{
    Console.WriteLine("Hello");
}

You can store that method inside a delegate:

csharp

Action action = PrintHello;
action();

Here:

Action is a delegate type
action points to the method PrintHello
calling action() invokes that method

A delegate is not just “syntax.” It is a real object that contains information like:

which method to call
and, for instance methods, which object instance to call it on

That second point is extremely important.

If you do this:

csharp

var worker = new Worker();
Action action = worker.DoWork;

then the delegate does not only know DoWork. It also keeps a reference to worker.

So conceptually it is like:

csharp

delegate -> target object (worker) + method (DoWork)

That means as long as the delegate is alive, the target object may also stay alive.

Instance method vs static method

This matters for leaks.

Static method

csharp

Action action = MyHelpers.Log;

A static method has no target object instance.

So the delegate only needs the method information.

Instance method

csharp

var vm = new ScreenViewModel();
Action action = vm.Refresh;

Now the delegate must remember vm.

So the delegate object holds a reference to vm.

That is why delegates can participate in memory retention.

What is an event?

An event is a language feature built on top of delegates.

Example:

csharp

public class Publisher
{
    public event EventHandler SomethingHappened;

    public void Raise()
    {
        SomethingHappened?.Invoke(this, EventArgs.Empty);
    }
}

Another object can subscribe:

csharp

publisher.SomethingHappened += subscriber.HandleSomething;

This means:

create a delegate for subscriber.HandleSomething
add that delegate to the event invocation list stored inside publisher

Conceptually:

csharp

publisher
  -> event field
      -> delegate list
          -> subscriber.HandleSomething
              -> subscriber instance

This is the whole leak story.

The publisher ends up indirectly holding the subscriber alive.

Why event syntax hides the important part

The code looks innocent:

csharp

publisher.SomethingHappened += subscriber.HandleSomething;

But in memory, this is not small or abstract. It is an actual object reference chain.

It is effectively like saying:

“Publisher, please keep a reference to this callback, and that callback points to subscriber.”

So if the publisher lives for a long time, the subscriber may also live for a long time.

How the leak happens

Now let’s build a real example.

csharp

public class MachineService
{
    public event EventHandler StatusChanged;

    public void OnStatusChanged()
    {
        StatusChanged?.Invoke(this, EventArgs.Empty);
    }
}

public class InspectionViewModel
{
    public InspectionViewModel(MachineService machineService)
    {
        machineService.StatusChanged += OnMachineStatusChanged;
    }

    private void OnMachineStatusChanged(object? sender, EventArgs e)
    {
        // Update screen
    }
}

Looks normal.

But imagine:

MachineService is a singleton or app-wide service
InspectionViewModel belongs to one screen only
user opens screen, then closes it

You expect InspectionViewModel to die.

But it may not.

Why?

Because memory still looks like this:

text

App / Singleton root
 -> MachineService
    -> StatusChanged event
       -> delegate
          -> InspectionViewModel

So from GC’s point of view, the ViewModel is still reachable.

And GC only removes unreachable objects.

So it stays alive.

Why this is called a leak in managed code

Some engineers get confused here and say:

“But GC exists. Why is this a leak?”

Because in managed systems, a memory leak means:

an object is still reachable, but only because of an unintended reference

So the GC is not failing.

Your object graph is wrong.

That is why managed memory leaks are really retention bugs.

Why this pattern is so common

Event leaks are extremely common because events are everywhere:

UI controls
background services
timers
message buses
domain notifications
hardware callbacks
reactive streams
global app services

And the code feels very harmless:

csharp

+=

That one operator can create a long-lived reference chain.

The dangerous lifetime pattern

The leak risk is highest in this situation:

publisher is long-lived
subscriber is short-lived

That is the dangerous direction.

Safe-ish direction

If a short-lived publisher references a long-lived subscriber, the publisher usually dies first, so no leak problem.

Dangerous direction

If a long-lived publisher references a short-lived subscriber, the subscriber may be kept alive forever.

So a useful rule is:

When subscribing to an event, always compare the lifetimes of publisher and subscriber.

That is one of the best senior-level heuristics.

A simpler everyday analogy

Imagine a company notice board.

The publisher is the notice board
The subscriber pins their contact card there

As long as the notice board keeps the card, the company still “knows about” that person.

If the person leaves the company but nobody removes the card, the board still points to them.

That is basically an event leak.

WPF example

This happens a lot in WPF.

csharp

public class ProductionScreenViewModel
{
    private readonly MachineMonitor _machineMonitor;

    public ProductionScreenViewModel(MachineMonitor machineMonitor)
    {
        _machineMonitor = machineMonitor;
        _machineMonitor.FrameReady += OnFrameReady;
    }

    private void OnFrameReady(object? sender, FrameEventArgs e)
    {
        // update image, counters, status, etc.
    }
}

If:

MachineMonitor lives for the whole application
each screen ViewModel subscribes on open
screen is closed but never unsubscribed

then every old screen may remain in memory.

And since the ViewModel may reference:

image buffers
collections
commands
services
child ViewModels

one event subscription can leak a very large graph.

Why leaks become large even from one small reference

A leaked object is often not just one object.

For example:

text

MachineService
 -> event delegate
    -> ViewModel
       -> ObservableCollection<ItemVm>
       -> BitmapSource
       -> Commands
       -> Child panels
       -> Selected item
       -> cached inspection result

So one event subscription may keep alive:

hundreds of small objects
several large objects
native image memory indirectly

That is why event leaks are disproportionately harmful.

What the GC sees

The GC does not know what “should” be dead.

It only knows reachability.

It asks:

is there a root?
can I walk references from that root to this object?

If yes, object stays alive.

For an event leak, the root chain is often:

text

static field / singleton / app object
 -> publisher
 -> event field
 -> multicast delegate
 -> subscriber instance

So the subscriber is considered alive.

Perfectly valid from the runtime’s perspective.

What is a multicast delegate?

Events can have multiple subscribers.

When multiple handlers are added:

csharp

publisher.SomeEvent += a.Handle;
publisher.SomeEvent += b.Handle;
publisher.SomeEvent += c.Handle;

the event stores a multicast delegate, conceptually like an invocation list.

So memory becomes something like:

text

publisher
 -> event delegate list
    -> handler A -> object A
    -> handler B -> object B
    -> handler C -> object C

So the publisher can keep many subscriber objects alive.

This is one reason global event aggregators can become leak factories if badly designed.

Lambda subscriptions make this harder to notice

This is even trickier:

csharp

publisher.SomeEvent += (s, e) => HandleUpdate();

csharp

publisher.SomeEvent += (s, e) => _logger.Log(Name);

Why is this tricky?

Because now the compiler may generate a hidden closure object if the lambda captures state.

For example:

csharp

publisher.SomeEvent += (s, e) => DoSomething(this);

This may create:

text

publisher
 -> event delegate
    -> closure object
       -> this

Now the leak is less obvious in code, but very real in memory.

So event + lambda can be worse than event + method group because it may introduce extra captured objects.

How to fix the leak

Basic fix: unsubscribe

If you subscribe:

csharp

publisher.SomeEvent += Handle;

then when done, unsubscribe:

csharp

publisher.SomeEvent -= Handle;

Example:

csharp

public class InspectionViewModel : IDisposable
{
    private readonly MachineService _machineService;

    public InspectionViewModel(MachineService machineService)
    {
        _machineService = machineService;
        _machineService.StatusChanged += OnMachineStatusChanged;
    }

    private void OnMachineStatusChanged(object? sender, EventArgs e)
    {
    }

    public void Dispose()
    {
        _machineService.StatusChanged -= OnMachineStatusChanged;
    }
}

This breaks the reference chain.

Now the publisher no longer holds the subscriber through the event.

Why unsubscribe must match the same handler

This works:

csharp

publisher.SomeEvent += Handle;
publisher.SomeEvent -= Handle;

Because it refers to the same method/target pair.

But this often fails conceptually:

csharp

publisher.SomeEvent += (s, e) => Handle();
publisher.SomeEvent -= (s, e) => Handle();

Those are usually different delegate instances.

So unsubscribe may not remove the original one.

That is why anonymous lambda subscriptions are dangerous unless carefully stored.

Better:

csharp

private EventHandler? _handler;

_handler = (s, e) => Handle();
publisher.SomeEvent += _handler;

// later
publisher.SomeEvent -= _handler;

When should you unsubscribe?

A practical rule:

subscribe when your object becomes active
unsubscribe when your object becomes inactive or disposed

In WPF this may correspond to:

screen open / close
ViewModel activation / deactivation
control loaded / unloaded
app start / app shutdown

The important thing is lifecycle ownership must be clear.

Weak event idea

Sometimes explicit unsubscribe is hard.

WPF has weak event patterns, for example WeakEventManager.

The idea is:

publisher does not hold a strong reference to subscriber
if subscriber is otherwise unreachable, GC can still collect it

This can reduce leak risk.

But weak events are not a magical replacement for good lifecycle design. They are a tool for specific cases, especially when publishers are long-lived and subscription cleanup is difficult.

Common real-world leak scenarios

1. Singleton service events

csharp

_machineService.StatusChanged += OnStatusChanged;

Service lives forever, screen should not.

High risk.

2. Timer events

csharp

_timer.Elapsed += OnElapsed;

Timer keeps firing and can keep subscriber alive.

3. Static event

csharp

SomeGlobalManager.Updated += OnUpdated;

Static event is especially dangerous because static is a GC root.

4. UI control events with reused screens

If screen subscribes to child control or global control manager and cleanup is sloppy, the whole visual tree can be retained.

5. Event aggregator / message bus

Very useful pattern, but if subscribers are not removed correctly, memory accumulates gradually.

How to recognize this leak in production

Typical symptoms:

memory grows every time user opens/closes a screen
old ViewModels remain in memory snapshots
memory never returns to baseline
duplicate event handling happens
same update processed multiple times by “dead” screens
app gets slower over hours

That duplicate handling symptom is a strong clue.

If a supposedly closed screen still reacts to events, it is probably still alive.

How a memory profiler would show it

In a profiler, you often see something like:

text

InspectionViewModel
 retained by
 MulticastDelegate
 retained by
 MachineService.StatusChanged
 retained by
 App singleton

That is the classic retention path.

The key question in memory debugging is always:

What is the path from GC root to this object?

For event leaks, the answer often goes through a delegate.

Senior engineer mental model for event leaks

Think like this:

1. Every subscription is also a reference decision

It is not just behavior wiring. It is lifetime wiring.

2. Compare lifetimes

Ask:

who lives longer?
who owns whom?
who should release whom?

3. Be suspicious of long-lived publishers

Singletons, statics, app services, timers, buses, monitors.

4. Be extra suspicious of lambdas

Because hidden closure objects can make retention less visible.

5. Put subscription/unsubscription in lifecycle boundaries

Do not scatter them randomly.

Minimal safe pattern

A very practical pattern is:

csharp

public sealed class ProductionViewModel : IDisposable
{
    private readonly MachineMonitor _monitor;
    private bool _disposed;

    public ProductionViewModel(MachineMonitor monitor)
    {
        _monitor = monitor;
        _monitor.FrameReady += OnFrameReady;
    }

    private void OnFrameReady(object? sender, FrameEventArgs e)
    {
        if (_disposed) return;
        // update state
    }

    public void Dispose()
    {
        if (_disposed) return;
        _monitor.FrameReady -= OnFrameReady;
        _disposed = true;
    }
}

This is not fancy, but it is robust.

Final summary for this leak type

An event handler leak happens because:

an event stores delegates
a delegate for an instance method holds the target object
the publisher therefore indirectly holds the subscriber
if publisher lives longer than subscriber, subscriber may never be collected

So the real core idea is:

publisher += subscriber.Handler is also a memory relationship, not just a messaging relationship.

We can continue with the next one: static/singleton reference leak, where I’ll first explain static field, application lifetime, GC roots, and why “global state” easily leaks whole object graphs.

Great — now we go to the second most common (and often more subtle) leak.

2. Static / Singleton reference leak

First understand: static fields and application lifetime

Before the leak, we need to clearly understand what static means at runtime.

What is a static field?

csharp

public class Cache
{
    public static List<string> Data = new();
}

Key properties of static:

Belongs to the type, not an instance
There is exactly one copy per AppDomain/process
It lives as long as the application lives

So in memory terms:

text

GC Root (type system)
 -> Cache.Data

That means:

Static fields are effectively GC roots.

Anything referenced by a static field is always reachable.

What is a singleton?

A singleton is usually implemented like:

csharp

public class MyService
{
    public static MyService Instance { get; } = new MyService();
}

So:

text

GC Root
 -> MyService.Instance

Same idea: it lives for the entire app lifetime.

Why static/singleton is dangerous

Because it creates a long-lived root.

And anything you put inside it becomes part of a long-lived object graph.

How the leak happens

Let’s start with a simple example.

Example 1 — Static cache

csharp

public static class GlobalCache
{
    public static List<OrderViewModel> Orders = new();
}

And somewhere:

csharp

GlobalCache.Orders.Add(viewModel);

Now memory looks like:

text

GC Root
 -> GlobalCache.Orders
    -> OrderViewModel
       -> UI data
       -> images
       -> child objects

Even if:

user closes the screen
UI is gone
nothing else references viewModel

…it still stays alive because:

text

static → list → viewModel

Why GC cannot collect it

Because from GC perspective:

static is a root
the list is reachable
the view model is reachable

So everything is valid.

Again:

This is not GC failure — this is your design holding references.

Real-world scenario (WPF / industrial app)

Imagine:

csharp

public static class InspectionCache
{
    public static List<InspectionResult> Results = new();
}

Each InspectionResult may contain:

defect list
measurement data
images (bitmaps)
metadata
references to machine state

Now:

user runs inspection → results added
user navigates away → UI gone
but cache still holds everything

Memory keeps growing.

Why this leak is more dangerous than it looks

Because:

1. It grows silently

Unlike event leaks (which may cause duplicate behavior), static leaks:

don’t break functionality
don’t throw errors
just increase memory

2. It often holds large graphs

One object is not small:

text

InspectionResult
 -> Bitmap (LOH)
 -> List<Defect>
 -> Metadata
 -> references to other objects

So:

text

static → list → many large graphs

3. It bypasses lifecycle boundaries

Normally:

ViewModel dies when screen closes
data dies when workflow ends

But static ignores lifecycle.

It says:

“Keep everything forever unless explicitly removed.”

Another variation — singleton service storing UI state

Example 2 — Singleton service leak

csharp

public class SelectionService
{
    public static SelectionService Instance { get; } = new();

    private object? _current;

    public void Set(object value)
    {
        _current = value;
    }
}

Usage:

csharp

SelectionService.Instance.Set(viewModel);

Now:

text

GC Root
 -> SelectionService.Instance
    -> _current
       -> ViewModel
          -> UI graph

Even after screen is closed, ViewModel stays alive.

Real-world version

“selected item” service
“current document” service
“active panel” reference
“global context”

These are extremely common in desktop apps.

Hidden version — dictionary or cache

Example 3 — Dictionary leak

csharp

public static Dictionary<string, object> Cache = new();

Usage:

csharp

Cache["last_screen"] = viewModel;

Or worse:

csharp

Cache[key] = largeImage;

If never removed:

text

static → dictionary → objects forever

The subtle trap: “it’s just caching”

Engineers often say:

“We need caching for performance.”

Yes — but caching without limits = memory leak.

Bad cache

csharp

static List<Image> Images = new();

No limit, no eviction.

Real consequence

LOH fills up
Gen 2 grows
GC pauses increase
memory never drops

Static reference + event = deadly combination

Sometimes leaks combine:

csharp

public static MachineService Service = new();

and:

csharp

Service.Event += viewModel.Handle;

Now:

text

static → service → event → delegate → viewModel

This is:

static leak
- event leak

Very common in real systems.

How to think about it (important)

The key question:

“Should this object really live for the entire application lifetime?”

If the answer is “no”, it should NOT be reachable from static.

Fix strategies

1. Remove references when done

csharp

Cache.Remove(key);

or:

csharp

Cache.Clear();

2. Use bounded cache

Instead of:

csharp

List<T>

Use:

size-limited cache
LRU (least recently used)
TTL (time-based expiration)

3. Store lightweight data, not heavy objects

Bad:

csharp

Cache[key] = ViewModel;

Better:

csharp

Cache[key] = viewModel.Id;

Then reload when needed.

4. Avoid storing UI objects globally

Never store:

ViewModel
Control
Window
Bitmap (without control)

inside static unless absolutely necessary.

5. Break references on lifecycle end

Example:

csharp

public void OnClose()
{
    SelectionService.Instance.Set(null);
}

6. Use weak references (advanced)

csharp

WeakReference<ViewModel>

This allows GC to collect object even if cache still holds reference.

But:

adds complexity
not always needed

How to detect this leak

Symptom pattern

memory increases steadily
never decreases
no obvious duplicate behavior
happens after repeated workflows

Profiling pattern

You’ll see:

text

ViewModel
 retained by
 Dictionary / List
 retained by
 static field

This is a very clear signal.

Why this leak is so common in senior codebases

Because it often comes from:

“quick solution”
“temporary cache”
“global access convenience”
“avoid passing parameters”

These feel harmless in the moment but accumulate over time.

Senior engineer mental model

Rule 1 — Static = forever

Anything referenced by static lives until process ends.

Always ask:

“Am I okay keeping this in memory forever?”

Rule 2 — Cache must have a policy

No policy = leak.

Every cache must define:

size limit
eviction strategy
lifecycle

Rule 3 — Do not store UI in global state

UI should follow screen lifecycle, not app lifecycle.

Rule 4 — Prefer flow over global state

Instead of:

csharp

GlobalCache.Store(obj);

Prefer:

pass data explicitly
use scoped services
use lifecycle-bound containers

Rule 5 — Small mistake → large impact

Because static sits at the root:

text

static → object → big graph → LOH → native memory

So one wrong reference can retain hundreds of MB.

Final summary

A static/singleton leak happens because:

static fields are GC roots
anything they reference is always reachable
if you store short-lived objects there, they become long-lived

So the core idea:

Static is not just “shared access” — it is lifetime escalation to application level.

Next, we’ll go to a very subtle and important one:

👉 Closure capture leak (lambda + async + hidden object graph)

This one is harder to see in code but very common in modern .NET.

Streaming Pipelines Dotnet Real World

Memory management and runtime performance in .NET ​

Internals and behavior ​

PART 1 — CORE CONCEPTS RECAP ​

Stack vs heap ​

Stack ​

Heap ​

Value types vs reference types ​

Reference types ​

Value types ​

Managed memory model in .NET ​

PART 2 — GARBAGE COLLECTOR INTERNALS ​

Generational GC ​

Gen 0 / Gen 1 / Gen 2 ​

Gen 0 ​

Gen 1 ​

Gen 2 ​

Ephemeral segment ​

What a collection cycle really does ​

Stop-the-world concept at a high level ​

PART 3 — LARGE OBJECT HEAP (LOH) ​

What goes to the LOH ​

Why large object allocations are expensive ​

Fragmentation concerns ​

Why image-heavy systems often hit LOH issues ​

PART 4 — ALLOCATION PATTERNS ​

Short-lived vs long-lived allocations ​

Short-lived allocations ​

Long-lived allocations ​

Allocation rate ​

Promotion between generations ​

Why high allocation frequency hurts performance ​

PART 5 — MEMORY PRESSURE & GC IMPACT ​

How memory pressure triggers collections ​

How GC pauses affect UI responsiveness ​

How long-running apps accumulate performance problems ​

PART 6 — WPF + MEMORY / PERFORMANCE ​

Object graph size in UI apps ​

Binding-related allocations ​

Image sources / bitmap memory concerns ​

Large collections and virtualization impact ​

PART 7 — PERFORMANCE MEASUREMENT ​

Throughput vs latency ​

Throughput ​

Latency ​

Allocation profiling ​

CPU profiling vs memory profiling ​

CPU profiling ​

Memory profiling ​

What metrics matter in production ​

PART 8 — COMMON LOW-LEVEL PITFALLS ​

Boxing allocations ​

Closure allocations ​

String-heavy hot paths ​

Unnecessary LINQ allocations ​

Event-handler memory leaks ​

Keeping references alive accidentally ​

PART 9 — ADVANCED OPTIMIZATION CONCEPTS ​

ArrayPool ​

Span<T> / Memory<T> at a high level ​

Pooling and reuse ​

When these optimizations are justified ​

PART 10 — SENIOR ENGINEER MENTAL MODEL ​

How to reason about allocations and object lifetime ​

1. Ask what gets allocated ​

2. Ask how often ​

3. Ask how long it lives ​

4. Ask who still references it ​

5. Ask whether the cost is CPU, memory, or latency ​

How to identify real bottlenecks before optimizing ​

How to balance code clarity vs performance ​

How to debug memory growth and GC-related production issues ​

1. Decide whether the problem is: ​

2. Observe trends ​

3. Take snapshots ​

4. Find retention paths ​

5. Fix lifetime ownership first ​

6. Optimize churn only after retention is understood ​

Final senior-level summary ​

Memory leaks in .NET ​

Memory management and runtime performance in .NET

Internals and behavior

PART 1 — CORE CONCEPTS RECAP

Stack vs heap

Stack

Heap

Value types vs reference types

Reference types

Value types

Managed memory model in .NET

PART 2 — GARBAGE COLLECTOR INTERNALS

Generational GC

Gen 0 / Gen 1 / Gen 2

Gen 0

Gen 1

Gen 2

Ephemeral segment

What a collection cycle really does

Stop-the-world concept at a high level

PART 3 — LARGE OBJECT HEAP (LOH)

What goes to the LOH

Why large object allocations are expensive

Fragmentation concerns

Why image-heavy systems often hit LOH issues

PART 4 — ALLOCATION PATTERNS

Short-lived vs long-lived allocations

Short-lived allocations

Long-lived allocations

Allocation rate

Promotion between generations

Why high allocation frequency hurts performance

PART 5 — MEMORY PRESSURE & GC IMPACT

How memory pressure triggers collections

How GC pauses affect UI responsiveness

How long-running apps accumulate performance problems

PART 6 — WPF + MEMORY / PERFORMANCE

Object graph size in UI apps

Binding-related allocations

Image sources / bitmap memory concerns

Large collections and virtualization impact

PART 7 — PERFORMANCE MEASUREMENT

Throughput vs latency

Throughput

Latency

Allocation profiling

CPU profiling vs memory profiling

CPU profiling

Memory profiling

What metrics matter in production

PART 8 — COMMON LOW-LEVEL PITFALLS

Boxing allocations

Closure allocations

String-heavy hot paths

Unnecessary LINQ allocations

Event-handler memory leaks

Keeping references alive accidentally

PART 9 — ADVANCED OPTIMIZATION CONCEPTS

ArrayPool

`Span<T>` / `Memory<T>` at a high level

Pooling and reuse

When these optimizations are justified

PART 10 — SENIOR ENGINEER MENTAL MODEL

How to reason about allocations and object lifetime

1. Ask what gets allocated

2. Ask how often

3. Ask how long it lives

4. Ask who still references it

5. Ask whether the cost is CPU, memory, or latency

How to identify real bottlenecks before optimizing

How to balance code clarity vs performance

How to debug memory growth and GC-related production issues

1. Decide whether the problem is:

2. Observe trends

3. Take snapshots

4. Find retention paths

5. Fix lifetime ownership first

6. Optimize churn only after retention is understood

Final senior-level summary

Memory leaks in .NET

What they really are