Correcting Common Async/Await Mistakes in .NET 8 - Brandon Minnick - NDC London 2024
Vložit
- čas přidán 10. 04. 2024
- This talk was recorded at NDC London in London, England. #ndclondon #ndcconferences #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndclondon.com/
Subscribe to our CZcams channel and learn every day:
/@NDC
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
#dotnet #csharp #code #aws #concurrency
Did you know that the .NET compiler turns our async methods into classes? And that .NET adds a try/catch block to each of these classes, potentially hiding thrown exceptions? It's true!
In this session, we will learn how to best use async/await in C# by analyzing how .NET compiles our async code.
Join me as we take an existing app and optimize its async code together, showing off performance gains, better exception handling, improved run-time speed, and smaller app size! - Věda a technologie
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
THIS WAS AWESOME.. RIGHT ON POINT. NOT TOO LONG, NOT TOO SHORT. GREAT JOB, THANKS..
The part about FrozenSet and FrozenDictionary is a misconception. Those two collections were not added because they are immutable, you already have ImmutableHashSet and ImmutableDictionary. You should keep using those in most circumstances. The Frozen ones are meant to be used when they are are created on startup, kept in memory, and repeatedly used afterwards. The creation cost is way higher, but the reading part is significantly faster, so they are not suitable for operations that create them on the fly and discard them after they are finished.
I didn't want to watch the whole video to see if Brandon Minnick changed anything, but I've seen an similar video from him over the years with the same misguided info. Here's the last one; my complaints are the top comment: czcams.com/video/zhCRX3B7qwY/video.html. Wish I had this guys confidence in being wishy-washy with the details.
Totally fair feedback. You're absolutely right - there is a higher cost to create `FrozenSet` than `IReadOnlyList` and `ImmutableList`. When running benchmarks on my app, I found that the additional performance cost was around 1ms. For this app, it's not much of a performance hit; for example, I'm not dropping any frames due to using `FrozenSet`. That being said, I appreciate the feedback and I will update my recommendations for using `FrozenSet` to include this caveat 💯
This is to be watched by every .net developer.
Awesome presentation. Thanks for showing the iasynenumerable idea . I saw it somewhere, used it, lost the code, and couldn't find it again. Gonna go back to using this. HERO!
Thanks! You're most welcome!
Great voice, great tempo and super captivating. Fantastic listen
Thanks so much!
46:36 Async/Await Best Practices
Great talk!
Thanks!!
For the issue with intelisense there is a recommendation to suffix async methods with Async. Not my favorit but in this case it would help
it was cool, ty
It doesn't feel right to put work in the constructor. Especially when you need to create a lot of view models at once for say a list . I usually have some other type of async Task method to initialize work it so I or my team don't need to remember some extension method I made a year ago to handle doing work in the constructor safely.
You also have to be very careful with using ConfigureAwait(false) before a collection clear. The ViewModel should have little to no knowledge of what or how the UI is bound to it. A UI team member may bind a list control to the Collection that is being cleared here. However if you add a ConfigureAwait(false) in the call before and the execution continues in a thread that is not the UI thread when the collection clear occurs it will fire change notification events in a different thread from the UI. This will crash the app as the control bound to the collection cannot be modified from a non-ui thread.
Agreed. In the .NET MAUI apps I've published to the app stores, I trigger this logic using the `OnAppearing()` method. But, for this talk it's a quick + dirty example to segueway into the pros + cons of `async void`.
Great talk. Quick question though. Why would you do work in a constructor at all? Constructors initialize memory, methods do logic. Most coding platforms I worked with (winforms, wpf, asp,etc) have a 'starting' method or event that you can use so that your constructor doesn't need any weird 'safe way to execute async void code'.
For instance, even though you created this safe approach to async void, you still cannot handle the error in a meaningful way (eg, showing it to the user). So, instead you choose the only left option which is to trace it out. Why would you do it in that way?
Some like the "init" qualifier for properties because they allow for flexibility while retaining safety. Unfortunately that initialization can't be deferred to an init-method (unless you call it in the constructor). Its also a good thing to have the object in the expected state whenever a check for "is not null" or "is " returns true, and there's a potential opening between ctor --> init-method for any such checks to occur, where some properties may not have been initiated. That would open the can of worms of locking etc.
@@djupstaten2328But why can't we have private constructor, and have public async factory method?
@@djupstaten2328 yes why don't just use Onload / Init method?
@@TheRPGminer you can, but this more of a self triggerred/invoked operations where you just creata an instance from a factory and it kicks in
Yup - agreed, I don't recommend triggering any async code in the constructor. In the .NET MAUI apps I publish to the app stores, I trigger this logic using the `OnAppearing()` method, not in the constructor. But, for this talk it's a quick + dirty example to segueway into the pros + cons of `async void`.
To handle the exception using `.SafeFireForget()`, you can pass in an Excecption Handler: `.SafeFireAndForget(ex => Trace.WriteLine(ex))`
In reality .net doesn't do all that thread switching. That is actually a misunderstanding that is being spread by others. When you await a Task, nothing actually happens, yes the state machine is generated, but there is no thread switch. The calling thread continues to execute the internals of the task synchronously. The only time a thread switch happens is when an actually async method is called. Seems counter intuitive but try it out. There are some fake async methods in .Net that don't make a thread switch, and there are real async methods like File IO that do actually yield. This behavior causes the same misconception about Task.Run(), ppl think that they forced a thread switch when in fact they didn't. Put an infinite loop inside Task.Run() and then don't await it. You'll see that your program halts, even though it shouldn't. Counter intuitive, but that's how it is. It is interesing how the ForceYield flag changes this, but without it, it will not actually switch threads in most cases.
this feels like the same video as this one:
czcams.com/video/zhCRX3B7qwY/video.html
Again?
Is it still inaccurate?
@@gregh2327 If there's any innacuraces in the video, please do let me know! I've iterated this talk over the last 8 years and have certainly made improvements based on the feedback I receive. It's never my intention to mislead anyone.
@@brandonminnick Thank you for responding and being open. I unfortunately don't have time to watch and do a write up; but a couple comments in here are astute. In previous talks, my frustration has been regarding discrepancies in how the CLR works and how you describe it working.
ConfigureAwait being true by default was a dumb desicion.
I initially disagreed, but now I'm on the fence. I think you'd find an equal number of people that disagree.
The whole .NET is a mistake ... let alone async