GOPbIHbI4

Вue to de-abstraction feature in .NET 10 we can eliminate all the overhead in the existing cases.

For instance, if you have Enumerable.Any with a delegate that captures instance state, the runtime can stack-alloc it, and (if it's small) to inline it. This will achieve the performance of a manual code that obtains span out of a list and "inlines" the delegate logic into the loop itself!

I feel we have a cargo cult on using ConfigureAwait without thinking too much.

I've seen cases when the application code was filled with it "to improve performance" or "to avoid deadlocks". And it was very hard to convince that this is not how ConfigureAwait should be used.

The same is true for libraries: if your library is specific to your application then you might decide (like the ASP.NET Core team) to stop using ConfigureAwait completely. It is needed for highly re-uses able libraries that can be used in different contexts, which is quite rare.

In this video I'm covering why we have ConfigureAwait in the first place and how to use it correctly.

P.S. There are lot of discussions how broken ConfigureAwait is and a lot of people propose the fixes - like having a library specific annotation to implicitly add ConfigureAwait(false) to every await, or not depending on the configuration. But those discussions are still opened on GitHub with no plans on fixing it.

P.P.S. Another way is to use runtime code generation like Fody, but most of the people are not going to use them.

.NET 10 has quite a few nice features, but probably one of the most impactful ones is de-abtraction: a set of changes in JIT that allows almost completely eliminate the abstraction cost in certain scenarios, like when foreaching over an interface instead of a concreate collection type.

ConfigureAwait is one of the most confusing aspects of asynchronous programming in C#. In this episode we'll cover why we ended up having it in the first place and what it does under the hood by debugging the ConfigureAwait with a custom synchronization context.

Async/await in C# can feel tricky, but it’s simple when you step through it.

This video shows how to debug async methods line-by-line to understand exactly how async/await works under the hood.

Hey folks. I don’t know about you, but I kind of tired of this Dispose(bool disposing) nonsense that is used in vast majority of projects. I don’t think this “pattern” ever made sense to anyone, but I think it’s time to reconsider it and move away from it to a simpler version: never mix managed and native resources, and just clean up managed resources in Dispose method. No drama and no Dispose(boil disposing).

If you happen to stuck with .NET Framework (or you have a library that targets .netstandard2.0) you still can use most of the C# language features that were released in the past 10 years or so.

There are a few tricks you can during the build to add custom attributes, or you can use PolySharp.

This video shows some neat recent C# language features and how to use them with .NET Framework or .netstandard.

2 weeks ago Google broke like 1/3 of the internet due to null pointer bug and the retry logic that didn't have the randomization.

This video shows .NET specific stuff on how to avoid such issues, but the ideas are the same for other languages as well.

Crashes due to NullReferenceException, race conditions, constructors that finish before the finalizers in .NET, and all the fun stuff!

In this video I talk about how tiered compilation caused a "memory leak" when migrating from .net core 3.1 to .net6.

Hey (mostly) #dotnet people:)

Just published another episode on Dissecting the Code YouTube channel.

The video shows how global events, hidden static collection and timers can cause memory leaks and the ways to avoid it.

I've started a YouTube channel about .net/C# internals, JIT, memory management etc.

It seems that there is still a confusion between the C# language versions and the target frameworks. Some people think that if they got stuck with full framework they’re stuck on C# 7.3 forever as well and can’t use some language feature like records. Which is not true. You can’t use all the language features for sure, but you can use like a vast majority of them.

You might be surprised how slow string interning is in non-native AOT .NET App, compared even to a simple string cache that will take you 10 minutes to write!

It is quite sad that a paid content like one from Pluralsight could provide a very bad advices on how to measure performance or how to use one or another language feature.

Spoiler: the benchmarking code had quadratic complexity instead of linear. Yes, in the course on performance.