📝 Lesson 3.3: Async Performance and Pitfalls

The Cost of Async

async/await is not free. When you mark a method async, the compiler generates a state machine (like iterators, Lesson 1.3) to manage its pauses and resumes. If the method actually suspends at an await, that state machine and the returned Task are typically allocated on the heap.

One important optimization the runtime already does: awaiting an already-completed Task doesn't allocate or suspend — it continues synchronously. This is why a method that often has its result ready (a cache hit) can be much cheaper than it looks — and it's the motivation for ValueTask.

ValueTask

A Task<T> is a reference type, so returning one allocates an object. ValueTask<T> is a struct (value type) that can wrap either an already-available result or a real task — avoiding the allocation when the result is ready synchronously.

// Hot path: a cache that usually has the value already
private readonly Dictionary<int, string> _cache = new();

public ValueTask<string> GetAsync(int id)
{
    if (_cache.TryGetValue(id, out string? cached))
    {
        return new ValueTask<string>(cached);   // no allocation — result is ready
    }
    return new ValueTask<string>(LoadAsync(id));   // falls back to a real Task
}

private async Task<string> LoadAsync(int id)
{
    string value = await FetchFromDbAsync(id);
    _cache[id] = value;
    return value;
}

ConfigureAwait

When you await, by default the runtime captures the current synchronization context and resumes the continuation on it. In a UI app that context is the UI thread (so you can safely touch controls after an await); in classic ASP.NET it was the request context.

// In library code: don't capture the caller's context
public async Task<string> LoadAsync()
{
    string data = await _client.GetStringAsync(url).ConfigureAwait(false);
    return Process(data);   // resumes on a pool thread — fine, no UI access needed
}

The Sync-Over-Async Deadlock

The most infamous async bug: calling .Result or .Wait() on an async method from a context that has a single-threaded synchronization context (classic UI or ASP.NET). Here's the trap:

The blocked thread is exactly the thread the awaited continuation needs to resume on — so neither can proceed. Two fixes:

• The real fix — go async all the way: await instead of blocking. Never call .Result/.Wait().
• Mitigation in library code: ConfigureAwait(false) means the continuation doesn't need the captured thread, breaking the cycle.

// ❌ Can deadlock in a UI/classic-ASP.NET context
string data = LoadAsync().Result;

// ✅ Await it — no blocking, no deadlock
string data = await LoadAsync();

async void and Fire-and-Forget

An async method should return Task, not void (you saw this in Intermediate — here's the deeper why). With async void:

• The caller can't await it — there's no Task to await, so you can't know when it finishes or that it succeeded.
• Exceptions can't be caught by the caller — they're raised on the sync context and typically crash the process.

// ❌ async void — exceptions escape and can crash the app
async void SaveData() { await File.WriteAllTextAsync(path, data); }

// ✅ async Task — awaitable, catchable
async Task SaveDataAsync() { await File.WriteAllTextAsync(path, data); }

More Pitfalls

// Sequential (slow) — each awaited before the next starts
foreach (var url in urls) results.Add(await FetchAsync(url));

// Concurrent (fast) — start all, then await
var tasks = urls.Select(FetchAsync);
var results = await Task.WhenAll(tasks);

// Slightly cheaper — no extra async state machine
public Task<string> GetAsync() => _client.GetStringAsync(url);

Exercise & Quiz

// 1) blocking
string s = LoadAsync().Result;

// 2) async void
async void ProcessAsync() { await Task.Delay(100); }

// 3) sequential loop
var results = new List<string>();
foreach (var url in urls) results.Add(await FetchAsync(url));

// 4) fire and forget
SaveAsync();

// 1) await instead of blocking
string s = await LoadAsync();

// 2) return Task, name it *Async
async Task ProcessAsync() { await Task.Delay(100); }

// 3) run concurrently
string[] results = await Task.WhenAll(urls.Select(FetchAsync));

// 4) either await it...
await SaveAsync();

// ...or, if it must be fire-and-forget, observe failures:
_ = Task.Run(async () =>
{
    try { await SaveAsync(); }
    catch (Exception ex) { Log(ex); }
});

Summary

📚 Additional Resources

• Async in depth — Microsoft Docs
• ValueTask<TResult> — API reference
• ConfigureAwait FAQ — .NET Blog

🚀 What's Next?

That completes Module 3 — you write async that's correct, controllable, and fast! In Module 4, we go deeper into performance itself. First: Lesson 4.1: The Memory Model — value vs reference types, stack vs heap, and boxing.