Actually my interest on ConfigureAwait extends to MAUI where they only ever load libs as either singleton or transient (concept of scope is a bit irrelevant on a single user app) but specifically the impact of async on a UI app where a lot of this stemmed from (if my memory serves)
Unless you have measured this is a hot path, avoiding async/await is a premature optimization in my opinion. Some people think many tiny performance gains will add up. But I think in most cases the bottleneck will be something else and the impact of async/await will be negligible. On the other hand, even if a method simply forwards the async call, losing the stack frame can result in losing time when debugging the code later. Especially if there are many layers of "forwarded async methods", it may be very hard to tell how execution ended up in a certain method. Of course, this doesn't apply to well-tested libraries that we wouldn't want to debug at all. That's why HttpClient doesn't use async/await where possible for example. Another reason is that library code doesn't "know" how it will be used, so it has to be optimized just in case. Note that I have encountered cases where a hot path actually benefited from removing async/await. But these cases are very rare from my experience. And I always had to measure performance before deciding how to optimize such cases anyway.
Use of async/await for sure. Even though the use of disposable is a big deal, the debugging problem is away bigger than that. Getting a more accurate exception stack is, in the majority of the scenarios, much more important than performance.
Great video!! I'm typically in the return Task camp myself. And I'd LOVE a video on ConfigureAwait as I've seen/read different things about whether or not it is needed in APIs.
I definitely prefer async/await personally. It's clearer to support and understand, especially on a large team of contributors, and the loss of performance in negligible in the vast majority of use cases.
I used to use Task returns myself and also recommended doing the same to others because it looked slightly more clear and I thought it would make fewer calls in the framework. However, once we struggled to diagnose and troubleshoot exceptions efficiently, I quickly switched to using 'await' everywhere. There is no debate, Task returns are evil.
Amazing video (again) thanks! 👍 I've had colleagues bashing me for using async/await rather than returning the task. However I think I now have some great arguments for keeping it! - An error shows in the stacktrace where awaited. - Potential gotchas with disposed variables. - Not that much slower. For majority of problems I sit with, performance has less priority than, potentially introducing bugs. The dispose one is particularly scary, cause it might only fail once in a while! I'd go with async/await all the time (unless I have a special case).
The only benefit of eliding the await is performance gain which I would guess is negligible in the majority of cases. If you get bashed again just turn the question around and ask for benchmarks to prove why eliding the await is beneficial in your use case against the more idiomatic usage of async/await (factoring in the gotchas e.g. exceptions, disposing, additional cognitive load of more junior members of the team understanding the nuance)
Great video, I've followed the rule of eliding await for "forwarding methods" and middleware, otherwise always await (unless it's performance critical). I like that you are sharing the nuance, not dogmatism
When I came over from old Fx WebForms days, I was taught to use async/await all the way. Today I don’t know any better 🤓 I would rather be safe and use it all the way to avoid confusion. Dunno how much perf hit would hurt in my typical LoB projects 🤔. And yes, a video about ConfgureAwait would be useful.
Yep I was thinking the same because curious about that too in this context (being used with async/await versus directly returned). I was thinking about it at the point about Task.FromResult being based on a value type versus reference type.
A fair rule of thumb is, if your function returns a value task, don’t do the unnecessary await, as the use of value task suggests the function will be called in a tight loop where the overhead of the state machine will start to matter more.
this also alters the behavior on the calling side, say you have two methods A and B that take some value and do the validation. 'A' after validation does an awaited db query, 'B' similar, but not awaited, just returns the task. Now caller can invoke this methods sequentially and await each, but it can also execute them without awaiting and do the awaiting a bit later. If validation fails for either of those methods then exception will be thrown at different stages: or execution or on await.
I have mostly used the version that does not use async and await. But interestingly enough in the last couple of weeks at work we experience some issues around tasks with deadlocks and one of my co workers found out that if we use async and await in the places that deadlock the deadlock disappears. So on the new year we will have an interesting week trying to decipher that. Your video helps shed some light. PS: fun fact that is the second time now where you publish a video that I was searching for. Such a nice coincidence Thank you for your time.
Another thing to consider is if your method has guard clauses. If you use the async/await keywords, the guard clauses won't throw until the caller calls await on the resulting task. Usually you would want guard clauses to throw immediately when the method is called. To get around this, you can move the work to another method that does use async/await, then have your main method (no async/await) just contain the guard clauses then call the second method and return it's task.
great insights Nick. I usually use async/await in most cases but I came across some code for writing a proxy application which would forward a client request to another external service, and they were using Tasks but wrapped in Task.Run() I kept wondering why they wouldn't just use async/await watching this video I now understand why that was the case very eye opening
When I don't need to await something in the middle of a method that returns Task (the last thing it does is call an async method that return a Task but nowhere else), I will not turn that method to async/await, but if anything in the middle of the method does require await (2 or more promise chaining), I will do async/await. Reason is... promise style ContinueWith(...) callback is a bit of a pain. I guess need to add another thing for the async/await which is when you use using statement in the method that calls an async method.
Outstanding explanation of returning task vs async-await... I just got into habit of using async-await without actually thinking about the difference. Thank you Nick!
A video on ConfigureAwait would be great! I had so many discussions with other developers when or when not to use it. At one point someone claimed that it should be used for literally every async call.. It would be amazing to be able to refer them to your video 😁
Configure await is used to refer to the main thread. So important to know when to use it coz it’s a performance impact and deadlock on certain cases. Useful for Maui app for ex but not in backend app.
@@FXK23 the standard is true to make sure you don’t get dead lock even if in majority you will use false. And configure await true doesn’t mean you get for sure a new thread. It’s just meant that the thread that we continue can be another one
This is exactly what I've been considering in my async heavy applications that run through multiple layers of calls, thank you for the clarity. And yes, a video on ConfigureAwait would be much appreciated. So many things I thought I understood properly until you made a video on it.
I thought from the thumbnail you were going to weigh up the pros and cons of making API calls using an async vs a sync method like the RestSharp synchronous methods vs HttpClient's async methods. It would be interesting to know what implications for the application both have.
You probably shouldn't be calling external API's (or internal, for that matter) synchronously because all that time between the start of the request till the end of the response, you are basically blocking your "thread" (whether that be an HTTP Request Thread for ASPNET.Core or the UI thread for WPF/UWP etc). Async/await is exactly for cases like these, where your thread can not do anything for a given time (reading the file, reading some data from some network etc.), and you do not want your thread (essentially the amount of processing power the CPU/OS gives you) just waiting for stuff.
So amazing topic...,. It could be so interesting discusing about this and the relation with pool starvation & concurrency. Thank you for your time and share your knowelge with all of us, greetings.
Another greate video Nick! I prefer using await and async, this avoids confusion to other develoopers join after i leave the contract. I guess i can offse the performance elsewhare btw.
I typically only use async/await if I either need the result of the task or want to handle the exception within that method. Otherwise, it seems pretty unnecessary to do so. You wouldn't call .ToList() on every IEnumerable you find just because it's easier and to avoid having to enumerate it to an array or list later on, right?
Excellent video as always! A video on ConfigureAwait would be greatly appreciated from my perspective but also going by a lot of the comments posted here! Thanks
Great explanation! I usually return the task itself when I need to await multiple tasks afterwards with task.whenall, but this gets me thinking there are many other use cases
async and await are implementation details. I think letting the caller decide how and when they want to await something is an important case that many haven't brought up. If you're awaiting immediately, you're making a decision for the caller, and therefore the caller would lose that control.
One of the other issues that I faced returning Task without an await, in the calling method it does not report anything if I miss await and async, while in the other case, it is reported with green squiggly. Former resulted in some difficult to debug bugs and wasted hours.
Thank you very much Nick, great video! You uploaded this video just in time when I was looking at David's guidance, after watching your older video about async await 😄
Async await is a long subject with a lot of details, reading a ton of things on the internet helped me out, including pages shown by Nick in the video. I have also been writing my own async state machine in order to get better understanding of it (after seeing those decompiled examples from ILSpy and Sharplab io) much like I have manually written IEnumerator iterator implementations for same reasons. I can almost recommend other people doing those things. Deep understanding of things you use every day can help a lot. Also a lot of experimenting with deadlock situations and high threadpool load. All to get a better idea what those smart people on the internet are talking about.
Great video, but be careful when benchmarking file access from disk, as you need to take into account any underlying caching mechanism such as those afforded by the operating system. In this case, it's probably not a deciding factor, as only the first call of the method doing the very first read would hit the disk and thus have have a higher latency. Edit: Depending on the size of the file and on how slow of a disk you read from, the initial latency could skew the benchmark result quite a bit (though, I suspect that this is not the case here)
Good video... I can say I wasn't surprised when file reading doesn't change much with async since it still has to read the file line by line... I found that even the TPL doesn't make file reading faster... I am careful as to what gets an ASYNC call. I can remember old style async with BeginInvoke...
I generally do return Task because I get suspicious of too much compiler-generated cruft in my assemblies but I'll keep the issue with disposal in mind, thanks!
Nick, I believe you have misunderstood David Fowler's point about exceptions in async methods being "wrapped in Task instead of surprising the caller with an actual exception". What David meant is this difference in behavior: async Task Main() { var task = this.Throw(); // Throw() causes an UnreachableException to be THROWN here while (!task.IsCompleted); Console.WriteLine(task.Exception); // ThrowAsync() causes task.Exception to be populated with an AggregateException that contains the UnreachableException } public Task Throw() => throw new UnreachableException(); public async Task ThrowAsync() => throw new UnreachableException();
I've always used flexible approach like in your final summary, I call it "make Rider happy". Often changing from async to returning tasks contaminating code with many Task.FromResult(...) / Task.CompletedTask, but I am ok with it. In most cases classes that have such "do something sync and then pass through" logic are abstract base classes, or static helpers/extensions.
Great video Nick, thank you! I have been using async/await more for the neatness and structure it brings to the code, without realizing the fact that it would create all those stacked up state machines. Will definitely have an impact on my future coding :)
Previously I would return the Task whenever possible. This does mean you need to refactor when adding a second async operation so that is a downside. Because of stacktrace and dispose issues I changed my default to 'async unless'
Depends. If the call is part of a complex Api with may levels I prefer returning tasks. Also if the tasks can be combined or the caller has the option to wait for all of them or not. Returning the task is much more flexible from the caller's perspective. Now, in the usual case I prefer to do exactly as you, mostly await and avoid it in trivial forwarding methods.
In hotpath code, I will write a non-async method that just returns the task (such as reading from a pipe) if it is already completed successfully (as it usually is). But if the task to be returned is not completed, the method will call an inner, async method that awaits it. So you get the benefit of hotpath not using async machinery most of the time, only using to it when the task hasn't completed successfully.
When he says "debugging hangs", he didn't mean that debugging hangs in the IDE, he meant debugging code which causes the application to hang. (Its a subtlety of English.) Because when you debug pause the application, you'll pause at the await of the internal task, not at the await of the calling task.
A link for the two articles mentioned would be great in the description. I use direct Task return when possible, but I burned myself previously with the using stuff, so I can understand the other camp too. I never had problems with debugging or stack traces with this approach.
Thanks so much for this important video, Nick! I've gone back and forth on returning a Task, and it's great to feel like the debate is settled. Do you know of any Code Analyzers which can make suggestions which follow your guidelines? I only know of "AsyncFixer" which goes the "return a Task" direction.
I think the state machine overhead is not what was meant with "performance difference". A task may or may not be awaited if many tasks are chained, and if there is an await in async methods it forces the await even if this task would not be awaited if some other task before it failed. Basically anybody who uses the code could create a performance difference depending on how is he using the code.
I like to mix it. The default is to include async await, but sometimes within Linq or fluent APIs, it is nice to elide the async await ceremony for more concise syntax. Sometimes it is also a good thing to be able to modify the call stack by hiding passthrough methods for example. For performance reason alone I would never use it, chances are one line of unoptimized user code amounts to thousands of occurences of eliding async / await in performance drag.
Nick. Great video again. Definitely since there is so much older stuff saying use ConfigureAwait it would be a good video. It would help to explain what it does (all that stuff out there mentions the SynchronizationContext but doesn't explain what that is, why you might care and when using ConfigureAwait(false) would actually be bad). Emphasize why Core is different, why doesn't it has this SynchronizationContext thing whatever it is?
If following DDD it can in some cases land up with excessive deep async await trees simply as a code base grows, but in some cases separation of concerns may end up with a few of these pseudo pass through methods as there just isn’t any specific logic required (or it’s been bedded down enough that the loss of exception visibility is acceptable)
We program a lot in the WPF world, therefore we often need to do work without blocking the UI, so in the view-model we create a core method that returns a Task and then create an async method that awaits that core method. Sometimes we even create a raw method, that is called from the async method as a simple wrapper task, but this is rare. If i ever see async methods called in a chain, i collapse them down to just one async method. Sometimes i prevent the usage of async entirely and use tasks and wait for them instead - it depends on the use-case. But i find it hard to properly secure the methods, so that it wont be called multiple times or can be canceled. Most of the time a simple Interlocked.CompareExchange() and one Exchange() can solve that, but in some cases where multiple calls are actually allowed, that requires much stronger syncronisations.
Our company just added a rule to our set of analysers to require async, to improve readability on leaf methods that would otherwise have to return Task.FromResult, and to help avoid returning a null Task, tho #nullable enable helps there too. They also suppressed the suggestion that async without any await could be removed.
One argument is that its more common to use async/await and easier to conceptualize for someone reading your code that may not be aware. I would only use it if performance matters.
If you need to use any peripheral device (slow access) - you must always use async/await. In a high load situation async/await works faster, always. imo )
There is no difference in what is being shown in this video. In both cases async await is used. You have to understand that it is NOT faster than the sync alternative. For example something like a Redis cache, will be slower if you use async await, but it will scale better.
yes! more info configureAwait please. I learnt a bit about it when using Unity engine and never again. I generally always declare "false" except for rare UI cases
I was hoping to see ValueTask compared in the benchmarks as well as that sounds like the intended compromise between async performance and functionality for tight-loop code
I wonder it's an implementation issue, ie even if we don't use await, it should point the actual line which the problem occurs and and also should dispose of correctly.
The biggest reason to NOT await the return is the removal of call site control. The caller has no option to await or not, it is forced to. Imagine wanting to create a list of tasks to await later. Adding await at the return would stall out the list creation. By omitting it, you allow the call site to await, but also allow it to defer the await.
I'm using only await/async just because of debugging and stack tracing. Though I had one project where some performance was increased just by failing debugability.
Yes, please make a video on ConfigureAwait! Great video, thank you
I have only one question to "ConfigureAwait", why they didn't make false as default?!))
This is one of the worst things about async in legacy code..
Would love to also get your thoughts on legacy code, specifically .NET Framework 4.7.1
yes yes, we do need this topic in detail please thank youuu.
Actually my interest on ConfigureAwait extends to MAUI where they only ever load libs as either singleton or transient (concept of scope is a bit irrelevant on a single user app) but specifically the impact of async on a UI app where a lot of this stemmed from (if my memory serves)
Unless you have measured this is a hot path, avoiding async/await is a premature optimization in my opinion. Some people think many tiny performance gains will add up. But I think in most cases the bottleneck will be something else and the impact of async/await will be negligible. On the other hand, even if a method simply forwards the async call, losing the stack frame can result in losing time when debugging the code later. Especially if there are many layers of "forwarded async methods", it may be very hard to tell how execution ended up in a certain method.
Of course, this doesn't apply to well-tested libraries that we wouldn't want to debug at all. That's why HttpClient doesn't use async/await where possible for example. Another reason is that library code doesn't "know" how it will be used, so it has to be optimized just in case.
Note that I have encountered cases where a hot path actually benefited from removing async/await. But these cases are very rare from my experience. And I always had to measure performance before deciding how to optimize such cases anyway.
I literally can’t get enough of these videos. And I actually use all this knowledge for my job.
Thank you for all your content!
Only for your job?
ALSO for their job 😉
Very useful videos
Use of async/await for sure. Even though the use of disposable is a big deal, the debugging problem is away bigger than that. Getting a more accurate exception stack is, in the majority of the scenarios, much more important than performance.
Great video!! I'm typically in the return Task camp myself. And I'd LOVE a video on ConfigureAwait as I've seen/read different things about whether or not it is needed in APIs.
I definitely prefer async/await personally. It's clearer to support and understand, especially on a large team of contributors, and the loss of performance in negligible in the vast majority of use cases.
I used to use Task returns myself and also recommended doing the same to others because it looked slightly more clear and I thought it would make fewer calls in the framework. However, once we struggled to diagnose and troubleshoot exceptions efficiently, I quickly switched to using 'await' everywhere. There is no debate, Task returns are evil.
Amazing video (again) thanks! 👍
I've had colleagues bashing me for using async/await rather than returning the task. However I think I now have some great arguments for keeping it!
- An error shows in the stacktrace where awaited.
- Potential gotchas with disposed variables.
- Not that much slower.
For majority of problems I sit with, performance has less priority than, potentially introducing bugs.
The dispose one is particularly scary, cause it might only fail once in a while!
I'd go with async/await all the time (unless I have a special case).
The only benefit of eliding the await is performance gain which I would guess is negligible in the majority of cases. If you get bashed again just turn the question around and ask for benchmarks to prove why eliding the await is beneficial in your use case against the more idiomatic usage of async/await (factoring in the gotchas e.g. exceptions, disposing, additional cognitive load of more junior members of the team understanding the nuance)
Great video, I've followed the rule of eliding await for "forwarding methods" and middleware, otherwise always await (unless it's performance critical). I like that you are sharing the nuance, not dogmatism
This is video is SO TIMELY. We're currently implementing async to our entire codebase. THANK YOU!
I've always used the await way. It seems simple and of course doesn't have using/disposing issue.
When I came over from old Fx WebForms days, I was taught to use async/await all the way. Today I don’t know any better 🤓 I would rather be safe and use it all the way to avoid confusion. Dunno how much perf hit would hurt in my typical LoB projects 🤔.
And yes, a video about ConfgureAwait would be useful.
A video about the pros/cons of Task vs ValueTask would also be great
I already have that
@@nickchapsas Apparently I already watched it :D Your videos are great to point our juniors to. Keep it up :)
Yep I was thinking the same because curious about that too in this context (being used with async/await versus directly returned). I was thinking about it at the point about Task.FromResult being based on a value type versus reference type.
with better enunciation
A fair rule of thumb is, if your function returns a value task, don’t do the unnecessary await, as the use of value task suggests the function will be called in a tight loop where the overhead of the state machine will start to matter more.
The most tricky part about C# is multi threading. It even makes code reviews considerably longer,
So i would appreciate more videos on the topic.
I hope you're not thinking that this video was about multithreading?? Because it really isn't. Because async await is not multi-threading.
Read "Concurrency in C# Cookbook: Asynchronous, Parallel, and Multithreaded Programming" by Stephen Cleary
@@jongeduard You are clueless about programming as this joke that calls himself a senior developer but is just a paid book reader.
I would love to see a ConfigureAwait video.
this also alters the behavior on the calling side, say you have two methods A and B that take some value and do the validation. 'A' after validation does an awaited db query, 'B' similar, but not awaited, just returns the task. Now caller can invoke this methods sequentially and await each, but it can also execute them without awaiting and do the awaiting a bit later. If validation fails for either of those methods then exception will be thrown at different stages: or execution or on await.
I use both. I return a Task whenever I'm developing a reusable library, and async/await in any other case.
I have mostly used the version that does not use async and await. But interestingly enough in the last couple of weeks at work we experience some issues around tasks with deadlocks and one of my co workers found out that if we use async and await in the places that deadlock the deadlock disappears. So on the new year we will have an interesting week trying to decipher that. Your video helps shed some light.
PS: fun fact that is the second time now where you publish a video that I was searching for. Such a nice coincidence
Thank you for your time.
Another thing to consider is if your method has guard clauses. If you use the async/await keywords, the guard clauses won't throw until the caller calls await on the resulting task. Usually you would want guard clauses to throw immediately when the method is called. To get around this, you can move the work to another method that does use async/await, then have your main method (no async/await) just contain the guard clauses then call the second method and return it's task.
great insights Nick. I usually use async/await in most cases but I came across some code for writing a proxy application which would forward a client request to another external service, and they were using Tasks but wrapped in Task.Run() I kept wondering why they wouldn't just use async/await watching this video I now understand why that was the case very eye opening
When I don't need to await something in the middle of a method that returns Task (the last thing it does is call an async method that return a Task but nowhere else), I will not turn that method to async/await, but if anything in the middle of the method does require await (2 or more promise chaining), I will do async/await. Reason is... promise style ContinueWith(...) callback is a bit of a pain. I guess need to add another thing for the async/await which is when you use using statement in the method that calls an async method.
Outstanding explanation of returning task vs async-await...
I just got into habit of using async-await without actually thinking about the difference.
Thank you Nick!
Such a high quality content, seriously: wow. Thank you very much for your content
The program with files tests is that the os may cache the file access so second access to the same file will be faster.
A video on ConfigureAwait would be great! I had so many discussions with other developers when or when not to use it. At one point someone claimed that it should be used for literally every async call.. It would be amazing to be able to refer them to your video 😁
Configure await is used to refer to the main thread. So important to know when to use it coz it’s a performance impact and deadlock on certain cases. Useful for Maui app for ex but not in backend app.
@@maxime4047 Isn't this standard false in .Net Core (just continue on a free thread)? Thought this was only relevant in .Net framework?
@@FXK23 the standard is true to make sure you don’t get dead lock even if in majority you will use false.
And configure await true doesn’t mean you get for sure a new thread. It’s just meant that the thread that we continue can be another one
I’d love the ConfigureAwait video, explaining synchronization context. I’ve never felt confident with that.
This is exactly what I've been considering in my async heavy applications that run through multiple layers of calls, thank you for the clarity. And yes, a video on ConfigureAwait would be much appreciated. So many things I thought I understood properly until you made a video on it.
I have been awaiting ever since you told us to Nick
Yes, please make a Video on ConfigureAwait - or put it in your next course :)
"Kevin is one of the people I actually follow"
Follow button: 2:58
I *always* await. "Premature optimization is the root of all evil" -- Donald Knuth.
I thought from the thumbnail you were going to weigh up the pros and cons of making API calls using an async vs a sync method like the RestSharp synchronous methods vs HttpClient's async methods. It would be interesting to know what implications for the application both have.
You probably shouldn't be calling external API's (or internal, for that matter) synchronously because all that time between the start of the request till the end of the response, you are basically blocking your "thread" (whether that be an HTTP Request Thread for ASPNET.Core or the UI thread for WPF/UWP etc). Async/await is exactly for cases like these, where your thread can not do anything for a given time (reading the file, reading some data from some network etc.), and you do not want your thread (essentially the amount of processing power the CPU/OS gives you) just waiting for stuff.
So amazing topic...,. It could be so interesting discusing about this and the relation with pool starvation & concurrency. Thank you for your time and share your knowelge with all of us, greetings.
Another greate video Nick! I prefer using await and async, this avoids confusion to other develoopers join after i leave the contract. I guess i can offse the performance elsewhare btw.
I typically only use async/await if I either need the result of the task or want to handle the exception within that method. Otherwise, it seems pretty unnecessary to do so.
You wouldn't call .ToList() on every IEnumerable you find just because it's easier and to avoid having to enumerate it to an array or list later on, right?
I am curious, what Benchmark measures while a test returns Task? Logically, in tests we have to await result of tested methods. IMHO
Excellent video as always! A video on ConfigureAwait would be greatly appreciated from my perspective but also going by a lot of the comments posted here! Thanks
Thank you Nick for your videos and Courses, they are really useful :)
I'd like to see a video about ConfigureAwaiter as well.
Happy Holidays!
Great explanation! I usually return the task itself when I need to await multiple tasks afterwards with task.whenall, but this gets me thinking there are many other use cases
async and await are implementation details. I think letting the caller decide how and when they want to await something is an important case that many haven't brought up. If you're awaiting immediately, you're making a decision for the caller, and therefore the caller would lose that control.
I love the way he says, "your done for" at 9:28
Great video! It'd be nice to have the ConfigureAwait video :)
One of the other issues that I faced returning Task without an await, in the calling method it does not report anything if I miss await and async, while in the other case, it is reported with green squiggly. Former resulted in some difficult to debug bugs and wasted hours.
Thank you very much Nick, great video! You uploaded this video just in time when I was looking at David's guidance, after watching your older video about async await 😄
Async await is a long subject with a lot of details, reading a ton of things on the internet helped me out, including pages shown by Nick in the video.
I have also been writing my own async state machine in order to get better understanding of it (after seeing those decompiled examples from ILSpy and Sharplab io) much like I have manually written IEnumerator iterator implementations for same reasons.
I can almost recommend other people doing those things. Deep understanding of things you use every day can help a lot. Also a lot of experimenting with deadlock situations and high threadpool load.
All to get a better idea what those smart people on the internet are talking about.
Danke!
Great video, but be careful when benchmarking file access from disk, as you need to take into account any underlying caching mechanism such as those afforded by the operating system. In this case, it's probably not a deciding factor, as only the first call of the method doing the very first read would hit the disk and thus have have a higher latency.
Edit: Depending on the size of the file and on how slow of a disk you read from, the initial latency could skew the benchmark result quite a bit (though, I suspect that this is not the case here)
Very good point. Thanks for mentioning that
also, that probably explains the relatively high standard deviation
Very good analysis with all the pros and cons of both alternatives.
Be consistent. Await always!
Super great video! I usually use without await, i guessed that it would affect the stacktrace but wasn't 100% until now.
Good video... I can say I wasn't surprised when file reading doesn't change much with async since it still has to read the file line by line... I found that even the TPL doesn't make file reading faster... I am careful as to what gets an ASYNC call. I can remember old style async with BeginInvoke...
We follow a simple rule: if your method it's a one-liner do not use async await, for everything else async await all the way.
I generally do return Task because I get suspicious of too much compiler-generated cruft in my assemblies but I'll keep the issue with disposal in mind, thanks!
Nick, I believe you have misunderstood David Fowler's point about exceptions in async methods being "wrapped in Task instead of surprising the caller with an actual exception". What David meant is this difference in behavior:
async Task Main()
{
var task = this.Throw(); // Throw() causes an UnreachableException to be THROWN here
while (!task.IsCompleted);
Console.WriteLine(task.Exception); // ThrowAsync() causes task.Exception to be populated with an AggregateException that contains the UnreachableException
}
public Task Throw() =>
throw new UnreachableException();
public async Task ThrowAsync() =>
throw new UnreachableException();
I've always been using explicit async/await approach. Recently I've used Task approach for extension methods that implement a functional pattern.
I've always used flexible approach like in your final summary, I call it "make Rider happy". Often changing from async to returning tasks contaminating code with many Task.FromResult(...) / Task.CompletedTask, but I am ok with it. In most cases classes that have such "do something sync and then pass through" logic are abstract base classes, or static helpers/extensions.
Great video Nick, thank you! I have been using async/await more for the neatness and structure it brings to the code, without realizing the fact that it would create all those stacked up state machines. Will definitely have an impact on my future coding :)
This was a deep dive I really needed. Thank you for this content.
Great video! Lot of things to learn from you. Yes make video on ConfigureAwait 👍
Yes, please make a video on ConfigureAwait! Great video, thank you!
Previously I would return the Task whenever possible. This does mean you need to refactor when adding a second async operation so that is a downside. Because of stacktrace and dispose issues I changed my default to 'async unless'
Depends. If the call is part of a complex Api with may levels I prefer returning tasks. Also if the tasks can be combined or the caller has the option to wait for all of them or not. Returning the task is much more flexible from the caller's perspective.
Now, in the usual case I prefer to do exactly as you, mostly await and avoid it in trivial forwarding methods.
Your content is among the best, Nick
Pleeeease do the video on ConfigureAwait.
I just don't get it.
In hotpath code, I will write a non-async method that just returns the task (such as reading from a pipe) if it is already completed successfully (as it usually is). But if the task to be returned is not completed, the method will call an inner, async method that awaits it. So you get the benefit of hotpath not using async machinery most of the time, only using to it when the task hasn't completed successfully.
When he says "debugging hangs", he didn't mean that debugging hangs in the IDE, he meant debugging code which causes the application to hang. (Its a subtlety of English.) Because when you debug pause the application, you'll pause at the await of the internal task, not at the await of the calling task.
👏 Exactly
A link for the two articles mentioned would be great in the description.
I use direct Task return when possible, but I burned myself previously with the using stuff, so I can understand the other camp too. I never had problems with debugging or stack traces with this approach.
I understand it well so I tend to pass through to the underlying task when it makes sense.
Yes please make a video on Configure Await. I sort of understand, but I know this would help me and all other software developers to understand.
Always inspired by your videos. Thank you for all the lessons. 🙃
YES to ConfigureAwait video. The write-ups out here are so dense and confusing AF. It's like reading a dry CS textbook explanation.
What about the case when you use a transient dependency inside that async method? It must be decorated with async/await. The same as with using
Thanks so much for this important video, Nick! I've gone back and forth on returning a Task, and it's great to feel like the debate is settled. Do you know of any Code Analyzers which can make suggestions which follow your guidelines? I only know of "AsyncFixer" which goes the "return a Task" direction.
Thank you for this video.
Please make a video about ConfigureAwait
I think the state machine overhead is not what was meant with "performance difference".
A task may or may not be awaited if many tasks are chained, and if there is an await in async methods it forces the await even if this task would not be awaited if some other task before it failed.
Basically anybody who uses the code could create a performance difference depending on how is he using the code.
I like to mix it. The default is to include async await, but sometimes within Linq or fluent APIs, it is nice to elide the async await ceremony for more concise syntax. Sometimes it is also a good thing to be able to modify the call stack by hiding passthrough methods for example. For performance reason alone I would never use it, chances are one line of unoptimized user code amounts to thousands of occurences of eliding async / await in performance drag.
Nick. Great video again. Definitely since there is so much older stuff saying use ConfigureAwait it would be a good video. It would help to explain what it does (all that stuff out there mentions the SynchronizationContext but doesn't explain what that is, why you might care and when using ConfigureAwait(false) would actually be bad). Emphasize why Core is different, why doesn't it has this SynchronizationContext thing whatever it is?
If following DDD it can in some cases land up with excessive deep async await trees simply as a code base grows, but in some cases separation of concerns may end up with a few of these pseudo pass through methods as there just isn’t any specific logic required (or it’s been bedded down enough that the loss of exception visibility is acceptable)
We program a lot in the WPF world, therefore we often need to do work without blocking the UI, so in the view-model we create a core method that returns a Task and then create an async method that awaits that core method. Sometimes we even create a raw method, that is called from the async method as a simple wrapper task, but this is rare. If i ever see async methods called in a chain, i collapse them down to just one async method. Sometimes i prevent the usage of async entirely and use tasks and wait for them instead - it depends on the use-case.
But i find it hard to properly secure the methods, so that it wont be called multiple times or can be canceled. Most of the time a simple Interlocked.CompareExchange() and one Exchange() can solve that, but in some cases where multiple calls are actually allowed, that requires much stronger syncronisations.
Our company just added a rule to our set of analysers to require async, to improve readability on leaf methods that would otherwise have to return Task.FromResult, and to help avoid returning a null Task, tho #nullable enable helps there too. They also suppressed the suggestion that async without any await could be removed.
Please get us a video about ConfigureAwait 🙏
One argument is that its more common to use async/await and easier to conceptualize for someone reading your code that may not be aware. I would only use it if performance matters.
7:53 ..and I'm going to create a new David class over here 😂😂
ConfigureAwait(false) is the immortal classic for interview. But it would be useful to refresh it for wider audience.
If you need to use any peripheral device (slow access) - you must always use async/await. In a high load situation async/await works faster, always. imo )
There is no difference in what is being shown in this video. In both cases async await is used. You have to understand that it is NOT faster than the sync alternative. For example something like a Redis cache, will be slower if you use async await, but it will scale better.
I always return Task when I can and only use await at the topmost call, but when I have calls to other Async methods, I use awair.
Just yesterday I accidentally didn't await my DB read and my connection was already disposed, exactly like shown in your video.
yes! more info configureAwait please. I learnt a bit about it when using Unity engine and never again. I generally always declare "false" except for rare UI cases
I was hoping to see ValueTask compared in the benchmarks as well as that sounds like the intended compromise between async performance and functionality for tight-loop code
At 1:35 you're browsing GitHub with a sidebar on the left - is that an extension, or a hidden feature? I can't seem to find it anywhere?
Yes please do a deep dive on ConfigureAwait
I wonder it's an implementation issue, ie even if we don't use await, it should point the actual line which the problem occurs and and also should dispose of correctly.
Yes please. Make a nice video on the synchronization context and configureawait
The biggest reason to NOT await the return is the removal of call site control. The caller has no option to await or not, it is forced to. Imagine wanting to create a list of tasks to await later. Adding await at the return would stall out the list creation. By omitting it, you allow the call site to await, but also allow it to defer the await.
Please make a video on ConfigureAwait! Great video, thank you
Please explain when to use and not use configureAwait (), also when to pass down CancellationToken isn't very clear for me, please explain that too.
Yes, please make a video on ConfigureAwait!, thank you
Please link your sources in the description. It really helps.
I'm using only await/async just because of debugging and stack tracing. Though I had one project where some performance was increased just by failing debugability.
Yes, please make a video on ConfigureAwait!
Absolutely do a video on ConfigureAwait let's end the confusion once and for all.