3 ms·

This is very true and a better explanation of the benefits of async/await than "Efficiency and Comfort" from the article. There are a lot of articles on async/a

by dhd415 10y ago

This is very true and a better explanation of the benefits of async/await than "Efficiency and Comfort" from the article. There are a lot of articles on async/await in .NET that use the example of off-loading a long-running operation from the GUI event thread. While that's a legitimate use, it obscures the true benefits which are most closely tied to throughput scalability. In other words, maintaining a relatively small pool of threads to service I/O completion events allows a machine to minimize the overhead of thread context switching that can become a bottleneck in a thread-per-operation model. Additionally, many people have the misconception that async operations are somehow faster than their sync counterparts. In fact, they're generally slightly slower, but a fully asynchronous server will be able to maintain a much higher level of throughput, usually with similar latencies, than a fully synchronous server. In other words, the principal class of applications that benefit from async/await are high-concurrency server applications. One more place I see these kinds of misconceptions is in naive benchmarks that purport to test async performance without using a concurrent workload. That tests only straight-line latency of individual requests and isn't the point of async. The benchmarks in the blog post above properly use a concurrent workload for testing.

JamesNK 10y ago
> In fact, they're generally slightly slower An async method is much slower (40x) compared to a normal sync method. If you're writing a high performance library you need to be careful to not repeatedly call a method decorated with async in a tight loop. Of course 40x times slower of extremely fast is still really fast but I found the overhead can add up really quickly. Good video on async/await and performance: https://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T https://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T
- dhd415 10y ago
  Did that 40x number come from that video? In my experience, any non-trivial async operation (e.g., a 2ms database insert in a fast OLTP system) is going to be on the order of 10-20% slower in straight-line operation latency than a sync operation while handling vastly more throughput.
  - JamesNK 10y ago
    It came from the video but I have personally found async methods to be significantly slower most of the time (although I've never sat down and figured out the exact amount). The reason for the performance hit is that a lot the time your async methods are actually completed synchronously, e.g. you read data from a FileStream with ReadDataAsync and instead of going to disk, the data was already cached in an in-memory buffer. When you hit that situation the overhead of the async - the state machine, not being able to inline the method, nesting everything in a try/catch, etc - makes it orders of magnitude slower than a normal method just fetching some data from a buffer. If your method is always async and is already taking 2ms then it doesn't matter, but you want to avoid the async in methods called in tight loops in performance critical code. The overhead can be significant.
- OniBait 10y ago
  I'm curious where the 40x slower figure came from. It would really depend on what you are doing inside the method. If the method is a small amount of "synchronous" code in a tight loop, then yeah, the overhead of the async call is going to outweigh any benefits (a few orders of magnitude slower). However, if your method is doing something like reading in a 40MB file to do some processing and calls the ReadAsync methods then the difference will be negligible and you get the benefit of better parallel throughput.

by dhd415 10y ago

JamesNK 10y ago

> In fact, they're generally slightly slower An async method is much slower (40x) compared to a normal sync method. If you're writing a high performance library you need to be careful to not repeatedly call a method decorated with async in a tight loop. Of course 40x times slower of extremely fast is still really fast but I found the overhead can add up really quickly. Good video on async/await and performance: https://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T https://channel9.msdn.com/Events/Build/BUILD2011/TOOL-829T

dhd415 10y ago
Did that 40x number come from that video? In my experience, any non-trivial async operation (e.g., a 2ms database insert in a fast OLTP system) is going to be on the order of 10-20% slower in straight-line operation latency than a sync operation while handling vastly more throughput.
- JamesNK 10y ago
  It came from the video but I have personally found async methods to be significantly slower most of the time (although I've never sat down and figured out the exact amount). The reason for the performance hit is that a lot the time your async methods are actually completed synchronously, e.g. you read data from a FileStream with ReadDataAsync and instead of going to disk, the data was already cached in an in-memory buffer. When you hit that situation the overhead of the async - the state machine, not being able to inline the method, nesting everything in a try/catch, etc - makes it orders of magnitude slower than a normal method just fetching some data from a buffer. If your method is always async and is already taking 2ms then it doesn't matter, but you want to avoid the async in methods called in tight loops in performance critical code. The overhead can be significant.
OniBait 10y ago
I'm curious where the 40x slower figure came from. It would really depend on what you are doing inside the method. If the method is a small amount of "synchronous" code in a tight loop, then yeah, the overhead of the async call is going to outweigh any benefits (a few orders of magnitude slower). However, if your method is doing something like reading in a 40MB file to do some processing and calls the ReadAsync methods then the difference will be negligible and you get the benefit of better parallel throughput.