I'm seeing a lot of confusion around Task.Delay(). While not apparent, it's important to know that this:
await Task.Delay(1);
does not wait 1 millisecond. Most of the time it'll wait at least 16 and possibly longer. There are 2 things in play here...
await Task.Delay(1);
does not wait 1 millisecond. Most of the time it'll wait at least 16 and possibly longer. There are 2 things in play here...
When you await a task, what happens is that task runs, and then after it runs, the rest of your method does. The task and the work after must be run by *something*, that's the thread pool. It has to have a thread available to do that, and it must be scheduled for it to happen.
Also, the Task.Delay() is at the mercy of timer resolution itself, that's generally 16ms. That's why you're not going to get that 1ms your expect. Then, after it completes, that next unit of work (called the continuation) has to be scheduled a run. Is a thread free? Maybe!
If a thread isn't available, well it gets to park in the Task queue and wait until one is. So in a busy application, your delay can be indefinitely longer than what you have specified. Specific delays and async just do not play well, due to this shared queue.
It's easy to test this yourself! Here's a super simple program only doing the delay...and a gist so you can tinker: gist.github.com/NickCraver/3df… 
As for the "why?". It boils down to processors. CPUs still aren't that power efficient *except when they're sleeping*. A lot of power efficiency comes from batching work together, waking up, doing it fast, then sleeping for as long as possible. OS makers call this "alignment".
If your CPU is constantly waking (and going to a higher frequency as a result, in most machine's default configuration these days), it's eating a lot more power to do so. And since most things don't need < 15-16ms resolution...it's what they do by default.
Games and other media bits that need high res timers can kick the timer resolution up to 1ms (or even lower), but this comes at a power and CPU utilization cost because updating those OS tick counts isn't free. Life is full of trade-offs, this is one of 'em.
Anyway, hope that helps you somewhere down the road! Always be aware of these timing and queue bits with Task when designing and debugging. The Task API hides a lot of complexity, but knowing a bit about a few basics underneath can go a long way...as with most things in life.
Oh, it's worth noting: when I say "most of the time", that's due to how continuations work and where .Delay() is often used. The initial await (say at the top level of a simple program) will be in the 1-16ms range, catching the first timer interval. Like this:
