Practice Now
C#
async programming
Task.Delay
performance issues
debugging

await Task.Delay takes longer than expected

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms
Complexity & PerformanceConcurrencyC# & .NETDebugging & Errors

Introduction

await Task.Delay(milliseconds) guarantees a minimum delay, not an exact one. The actual wait can be longer due to the system timer resolution (typically 15.6ms on Windows), thread pool saturation, synchronization context overhead, and GC pauses. A Task.Delay(100) might actually wait 109ms or 115ms. If you need precise timing, Task.Delay is the wrong tool. Use a high-resolution timer or Stopwatch-based loop instead.

Windows Timer Resolution

The Windows system timer fires at a default interval of 15.625ms (64 Hz). Task.Delay uses this timer internally:

csharp
1var sw = Stopwatch.StartNew();
2await Task.Delay(1);  // Request 1ms delay
3sw.Stop();
4Console.WriteLine($"Actual: {sw.ElapsedMilliseconds}ms");
5// Output: Actual: 15ms or 16ms (not 1ms!)

Task.Delay(1) does not wait 1ms. It waits until the next timer tick, which is up to 15.6ms away. Any delay under 16ms effectively becomes a 16ms delay.

csharp
1// Timer resolution effects on various delays
2await Task.Delay(1);    // Actual: ~16ms
3await Task.Delay(10);   // Actual: ~16ms
4await Task.Delay(16);   // Actual: ~16ms or ~31ms
5await Task.Delay(20);   // Actual: ~31ms
6await Task.Delay(50);   // Actual: ~62ms
7await Task.Delay(100);  // Actual: ~109ms

The actual delay is rounded up to the next multiple of 15.6ms.

Thread Pool Starvation

When all thread pool threads are busy, the continuation after await Task.Delay must wait for a free thread:

csharp
1// Saturate the thread pool
2var tasks = Enumerable.Range(0, 1000).Select(_ => Task.Run(() =>
3{
4    Thread.Sleep(5000);  // Block pool threads
5})).ToArray();
6
7// Now Task.Delay completion is delayed waiting for a free thread
8var sw = Stopwatch.StartNew();
9await Task.Delay(100);
10sw.Stop();
11Console.WriteLine($"Actual: {sw.ElapsedMilliseconds}ms");
12// Output: Actual: 5100ms+ (waited for pool threads to free up)

The delay timer fires on time, but the continuation cannot run until a thread pool thread is available.

SynchronizationContext Overhead

In UI apps (WPF, WinForms), await captures the synchronization context and resumes on the UI thread:

csharp
1// WPF button handler
2private async void Button_Click(object sender, RoutedEventArgs e)
3{
4    var sw = Stopwatch.StartNew();
5    await Task.Delay(100);
6    // Must marshal back to UI thread, adds overhead
7    sw.Stop();
8    Console.WriteLine($"Actual: {sw.ElapsedMilliseconds}ms");
9    // Could be 120-150ms if UI thread is busy rendering
10}

If the UI thread is busy (rendering, handling events), the continuation waits in the dispatcher queue.

csharp
// Fix: use ConfigureAwait(false) when you don't need the UI thread
await Task.Delay(100).ConfigureAwait(false);
// Continues on a thread pool thread, faster resume

GC Pauses

Garbage collection can pause all managed threads:

csharp
1// If a GC occurs during the delay period
2var sw = Stopwatch.StartNew();
3await Task.Delay(100);
4// GC pause of 20ms → actual delay is ~120ms
5sw.Stop();

Server GC mode and concurrent GC reduce pause times but cannot eliminate them entirely.

Measuring Accurately

csharp
1// Use Stopwatch for accurate measurement
2var sw = Stopwatch.StartNew();
3await Task.Delay(100);
4sw.Stop();
5
6// ElapsedMilliseconds rounds down. Use Elapsed for precision
7Console.WriteLine($"Elapsed: {sw.Elapsed.TotalMilliseconds:F2}ms");
8
9// Measure multiple iterations for average
10var times = new List<double>();
11for (int i = 0; i < 100; i++)
12{
13    sw.Restart();
14    await Task.Delay(50);
15    sw.Stop();
16    times.Add(sw.Elapsed.TotalMilliseconds);
17}
18Console.WriteLine($"Average: {times.Average():F2}ms");
19Console.WriteLine($"Min: {times.Min():F2}ms");
20Console.WriteLine($"Max: {times.Max():F2}ms");

Improving Timer Resolution (Windows)

csharp
1// Request 1ms timer resolution (Windows only)
2[DllImport("winmm.dll")]
3static extern uint timeBeginPeriod(uint period);
4
5[DllImport("winmm.dll")]
6static extern uint timeEndPeriod(uint period);
7
8timeBeginPeriod(1);  // Set resolution to 1ms
9try
10{
11    var sw = Stopwatch.StartNew();
12    await Task.Delay(1);
13    sw.Stop();
14    Console.WriteLine($"Actual: {sw.ElapsedMilliseconds}ms");
15    // Output: Actual: 1ms or 2ms (much closer to requested)
16}
17finally
18{
19    timeEndPeriod(1);  // Always restore default resolution
20}

timeBeginPeriod(1) increases power consumption system-wide. Only use it when precise timing is critical, and always restore with timeEndPeriod.

Alternatives for Precise Timing

csharp
1// High-resolution spin wait (burns CPU but precise)
2static async Task PreciseDelay(int milliseconds)
3{
4    var sw = Stopwatch.StartNew();
5    while (sw.ElapsedMilliseconds < milliseconds)
6    {
7        if (milliseconds - sw.ElapsedMilliseconds > 15)
8            await Task.Delay(1);  // Yield to avoid pure spin
9        else
10            Thread.SpinWait(100);  // Spin for final precision
11    }
12}
13
14// PeriodicTimer (.NET 6+) for repeated intervals
15using var timer = new PeriodicTimer(TimeSpan.FromMilliseconds(100));
16while (await timer.WaitForNextTickAsync())
17{
18    // Fires every ~100ms, self-correcting for drift
19    ProcessTick();
20}

PeriodicTimer corrects for drift over time. If one tick is late, the next tick fires sooner.

Task.Delay(0) Behavior

csharp
1await Task.Delay(0);
2// Does NOT yield the thread. Returns immediately (synchronously)
3// Use Task.Yield() if you want to force a yield
4
5await Task.Yield();
6// Forces the continuation to be scheduled asynchronously

Common Pitfalls

  • Expecting exact timing: Task.Delay is a minimum-delay timer, not a precise one. It is never shorter than requested but can be significantly longer.
  • Using Task.Delay for game loops: Game loops need consistent frame timing. Use Stopwatch to measure elapsed time and adjust, or use a dedicated game timer.
  • Thread.Sleep vs Task.Delay: Thread.Sleep blocks the thread (cannot be cancelled, wastes a thread). Task.Delay releases the thread. Always prefer Task.Delay in async code.
  • Ignoring ConfigureAwait: In UI apps, await Task.Delay(100) resumes on the UI thread. Use .ConfigureAwait(false) when you do not need the UI thread to reduce latency.
  • Cumulative drift: Running await Task.Delay(100) in a loop accumulates error. After 100 iterations, you might be 500ms late. Use PeriodicTimer or a Stopwatch-based correction loop.

Summary

  • Task.Delay guarantees a minimum delay, not an exact one
  • Windows timer resolution (15.6ms default) is the primary cause of extra delay
  • Thread pool starvation, synchronization context, and GC pauses add further overhead
  • Use ConfigureAwait(false) to avoid UI thread marshaling overhead
  • Use PeriodicTimer (.NET 6+) for drift-correcting repeated intervals
  • For sub-millisecond precision, use Stopwatch-based spin loops (at the cost of CPU usage)
Related reading
Course
Intermediate
27 lessons
15 hours
DSA Fundamentals

Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms
Codemia
© 2026 Codemia
Resources
Legal
Social
All Rights Reserved.