These kinds of easy optimization tips is my favorite type of content from you Nick. Making the world a more informed place, 0.2239ns at a time

Praise from a random viewer: I’m very much a reader, and if I expect an article and land on a video, I’ve already hit the back button. Your videos are not only excellent enough to transcend my prejudices, but to provide some income with perks as well. Many thanks from an internet stranger for your fantastic work.

I hate this advice because I have managed to fix so many broken framework and library classes over the years by using inheritance. And entire avenue of bug fixing possibilities are quickly disappearing. These classes are not intended to be inherited and extended and these fixes are brittle but at least they're possible. I'd rather be able to work around an issue today and fix my workaround tomorrow than just be stuck.

I solved this issue a long time ago by changing the class template in ReSharper/Rider to internal sealed. My goal was not to improve performance, but to not accidently exposing a API I don't indent to expose. It's nice to see that the performance is also benefiting from it.

Like every advice from every "guru", sealed classes in every language are usable in small number of use-cases. If you can't inherit a class then every framework that is depending on proxy design pattern (for creating "sugar" classes) will fail and the list of frameworks is very large RestControllers, ORMs, DI etc. And why those framework will fail ? Because all of them depend on proxy design pattern, which can be implemented in three ways 1. as a pair (interface and class) or 2. as inheritance of the class annotated with metainformation. 3. provide factory methods for every sealed class, that will be use by the frameworks (mostly use in DI) If you are using sealed then you must 1 or 3 This means every seal class needs to have "dummy" interface in order for the framework A to create "the sugar" sealed class or factory method Congratulations, instead of one "sugar" class A, know you have sealed one "sugar" class A + dummy interface IA / factory method and your code base is now twice as big. Don't get me started on ORMs, there is a high change that the amount of SQL generation will be double or you will wonder why ORM always generates insert statements. But this is just the software developer perspective From library POV - in order to fight sealed word, the libraries have to provide compiler hooks and now instead of Microsoft or your fav language company you have to wait 3-rd party company to fix your compiler bugs Classes shouldn't be sealed by default, because they are almost always useless

Thank you for this video. I enjoy videos about the performance and features of C#. By the way, I wanted to mention that in .NET 8 (I tested it on .NET 8.0.101), there are no significant changes in performance when running methods and changing arrays to spans. However, other cases still show the same performance differences. This means that it’s still important to seal your classes in .NET 8.

New coder here. What I took away was “sealing classes not meant for inheritance = better performance”.

There should be a setting which instructs the compiler to make all classes in a project sealed if they are not inherited. Could be usefull when you don't plan to roll out your code as a reusable library, which is most often the case.

You'd think the runtime could handle this. The jitter knows if any classes inherit from this one, and if additional assemblies are loaded at runtime then the affected code could be re-jitted.

Sealed can be very annoying too. Like when you want to modify third parties code. Extend it and modify one function you want. With composition you cannot input it into functions that take the original class, only that take an interface, so you have to copy all the functions too that take or depend on original class.

As a kotlin dev, I really like the sealed nature of language, But coming from Java/C# background, I used to have a mindset that classes should allow for inheritance. I used to think that just encapsulation means a lot of objects running around in memory. It took me a while, a good mentor, and a lot of performance benchmarks to realize the runtime benefits far exceeds the memory overhead, and also that a badly designed inheritance will actually consume more memory than encapsulating multiple objects. Great video as always. I really love all the benchmarks numbers that you show to validate your tips.

As a frequent C programmer, one of the things I appreciate about C# is the ability to throw an OOP concept or trope like garbage collection overboard. There's definitely a place for them, but if I'm doing something like DSP it can be a performance factor of over a thousand just to clean up after myself instead (unchecked, unsafe), and work with buffers directly. So, I appreciate the occasional "do we always need this" introspection from the C# team.

I've been using c# as my main horse for over a decade, even wrote transpilers to IL and still learned something new today, thanks!

I jumped in hoping for a great performance boost after sealing ~1800 classes in my project. Perf increased by 0.3% overall. So kind of a mixed bag... Ah well, thanks for covering the fundamentals

I love the little Hello World eastereggs! Such a personal touch

Totally agree. Having been a Kotlin developer for the past few years, I've learned to appreciate sealed (or final) by default, and now I apply it as a matter of habit to C# projects. Whilst .NET doesn't implement sealed by default for classes, it does for structs, which is why you can't extend them. If you look at the IL for a struct, you'll notice they're marked sealed, and as .NET has no mechanism to 'unseal' a type, you simply can't extend them. The other thing that would be nice is if C# had a language-level equivalent of Kotlin's 'sealed' (which is not the same as C#'s sealed), where you can create an abstraction that is only intended to be implemented within the same assembly. You can achieve this however by using internal constructors, so that it's not possible for extension beyond the current assembly.

In a comment I made on one of your previous videos, I mentioned the preferred "composition over inheritance" pattern and got so much pushback. Glad to see you mentioning this as well!

Yeah! Since I played along with Kotlin some years ago, I got used to sealing all my classes in c#. It is not only a question of performance but, first of all, good an robust design of my code.

Unfortunately, I disagree with your assessment that we should seal for performance reasons and to stop others from inheriting our public classes (even though we cannot imagine how/why they would want to do that). Why limit what other developers can do with our code? Internal classes? Fine. Public classes? Never. I don't know how someone else may want to expand on this code, so why would I arrogantly seal it? This is the one thing that has pissed me off in the past: I'm trying to setup tests around some process, I need an instance of this object, and boom, I cannot create an instance for testing purposes (by inheriting and mocking the properties/methods) because the class is sealed. Terrible. Both middle fingers to Microsoft for making some of their public classes sealed - hours wasted.

The Microsoft Documentation from April 2022 says: DO NOT seal classes without having a good reason to do so. "Sealing a class because you cannot think of an extensibility scenario is not a good reason. Framework users like to inherit from classes for various non-obvious reasons, like adding convenience members. See Unsealed Classes for examples of non-obvious reasons users want to inherit from a type. ..." Also Mocking is a Problem.... thoughts?

I like the numeric values you use as examples.

This is not a "design flaw". This is a historical artifact of object oriented languages where classes are designed to be inherited by default. This also permit classes in libraries to be extended. Clearly over the years there's been a move away from object orientation with better methodologies of extending features. C# was based on Java and other OO languages at the time.

Interesting....One case you need to be careful is if you have created a nuget package / dll and you seal a class that would be very useful for your user to inherit from. This has happened to me and it caused me alot of pain.

I think if ide(s) like Rider and Visual Studio add this feature (Adding sealed keyword in snippet code of Creates a class declaration) It will be reasonable and more practical.

The performance improvement on the methods suggests that they are being inlined, and the performance improvements on the is / as would be because it can directly check the type instead of checking if the type being tested is assignable from the type of the value.

You noticed in this video that inheritance now is considered an antipattern. I tried to find some nice examples of how we can replace inheritance with composition, but I couldn't find some nice examples. Could you please make a video on how we can refactor code with inheritance to the composition?)

Change your class template in your IDE to include sealed by default (and make them internal while you're at it).

I'm curious if this has any effect after the code is converted using IL2CPP as is often the case when making final builds on Unity. Really interesting and awesome never the less!

Hey Nick I'd like to say thanks for your video and I have a question. The performance sag in your example could be a consequence of the virtual method table (not just because of "sealed" class). If you try to remove the "virtual" word you will see the other results. It does not negate the fact that type casting and some other operations are faster with sealed classes, but I think the "sealed" is not something that always makes performance better.

I totally agree with this, and I was thinking maybe change the New Class template that Visual Studio uses to create sealed classes?

Can you do a video about the inheritance anti-pattern?

I usually always avoid implementation inheritance. So I have been doing this for a while. And even the general rule is: either design for implementation inheritance or forbid it. I usually design for interface inheritance, so yes, of course I seal my classes since I am not designing them for implementation inheritance.

This may be great in theory, but in practice when trying to test either legacy systems or library without a good testing strategy. Sealed classes have stopped me from writing unit test many times. Especially when you want to implement tests without changing legacy code. For new systems it might be more applicable, but they will be legacy system one day. So how do you want to leave the code for future developers.

Hey Nick, thanks for the great video. I have two questions. 1. Is the performance difference only in .net 7, or is it in older veresions as well (.net 6, 5, .net core, .net framework)? 2. Usually there's no such thing as free lunch. In the video you displayed making class sealed (if possible) as an absolute positive, with no negatives. Are there some known drawbacks to doing it? Thanks :)

Wow! I had no idea the performance difference that existed between. I'm really glad I watched this!

6:10 it's easy to fall into a pit of misconception, so I'll drop my thoughts there Notice those ZeroMeasurement warnings down there, those say that method duration is too small to be taken into account, often times because the method is inlined and its execution takes virtually the same time as calling an empty method, meaning it's "the fastest you can get" when comparing vs calling a method. So it's not actually "38x" faster or "1000x" faster, it's "the fastest you can achieve".

I've been making my classes sealed by default for years now. I don't do it for performance reasons (though every little bit helps!), I do it because I don't like to use inheritance when I don't have to. "Prefer delegation over inheritance", etc. I only wish VS made it easier to change the default class template, so I could make those changes more quickly and easily.

Nice and short as always, great video

So I had a look as to WHY, and it's mainly because a call to a VLT can be being turned into a direct call by the compiler, which makes sense (still not idea why the 'is' and 'as' operators run faster though) [edit]Same idea, the runtime doesn't need to walk the inheritance hierarchy.[/edit] I suspect that this will have less of an impact if you have a deep inheritance tree with all of the leaf classes marked as sealed, because any method that at runtime can accept the base class will still have to do a lookup. That said, if people stick to composition > inheritance that shouldn't be an issue ;-)

I agree. The largest accurately measured specimen of the elephant seal was a bull which weighed at least 4 tonnes.

We really need a way to specify different c# 'versions' so features can be changed retroactively without having to worry about backwards compatibility. Any new project will use the most up to date recommended version and if an older project is upgraded, they can change individual settings to reenable compatibility modes. I think that would be awesome.

Ive been making everything sealed for a while now but it is a chore to remember, especially for juniors. I think they should add an unsealed keyword anyway, that way they could have warnings on public types that don’t specify it explicitly.

Probably your best advice until now. Thanks!

Ok this will be interesting. I have never used sealed before.

I Think that with the new feature of C# "Extension everything" this could be adopted in very fast way

I've been sealing all my classes since forever. I'm happy this performance gain and lock down of inheritance is becoming more mainstream now. Thank you Nick

As a Kotlin dev who has been dealing with libraries with insufficient extensibility, I have to disagree. If an open class does not have any sub-class, then it should be JIT's job to optimize it's virtual calls (devirtualization).

Rider has an inspection severity setting for this outside of .NET 7 under Settings / Inspecting Settings / Inspection Severity / C# / Class can be made sealed (non-inheritable)

Absolutely love this video. Thanks a lot for this video.

Thank you Nick. You just made me christmas

8:26 I can see why you did that ;).

It all reminds me of a thing that the C# designers did right: methods are non-virtual by default. Java is in fact worse, you need to explicitly make your methods final. I have learned earlier that virtual methods are slow, because they require the runtime to perform checks along the inheritance tree all the time. But to be honest, I was not aware of such a thing to be te same on the level of entire classes. But it is a logical thing, all for the same reasons. I think of course we can all criticize this, but the idea behind those languages started with inheritance in mind as a general feature. Mindsets where very different in the past. The idea of gaining the far best performance like native code was already given up anyway I guess. Flexibility is what counted.

Apart from performance and clarity reasons, sealing the class which implements IDisposable saves you from not implementing dispose pattern

Well you learn something new everyday! Thanks Nick

.. and in no time , best practice SOLID "enhances" to SLID. All this for attacking prematurely a performance -potential- issue-that-really-needs-this-tiny-perf-gain

Please avoid doing this for libraries. This is all nice and fine on paper, but if you seal a class in your library and I am using it and you haven't done something that I need, I have no way of overriding your classes to implement my behavior. You do not have a crystal ball to know how people are going to use your library, and people do not have weeks or even months of them begging you to implement a new feature / fix just so it fixes one main problem for them that you didn't think of.

Loved it. Thank for sharing!!!

I tried that, but notice you can't seal some entities when using dotnet EF because they use a Proxy for the DB

Always wondered about this , thanks!

I couldn't agree more with this video. I check for this in code reviews and insist that things be sealed unless explicitly needed otherwise.

While C# copies Java's classes are not "final" by default idea, all methods are non virtual by default in C# unlike Java. While adding a simple "unsealed" keyword might be seemed a little change, it will cause angry email's, long code reviews. So unsealed by default let OOP techniques to be used without a drama. The same can be said for static. Why not make every method, variable static. Less garbage collection, less memory, faster code ? Stack Overflow is using it ????

Is the difference only measurable in newer versions of .NET? Or will it be worth sealing all classes in .NET Core 3.1 as well?

Before watching: I Absolutely hate SEALED, cannot estimate how many hours waisted copying disassembled classes and still failing to customize what I needed.

Excellent article Nick thanks , I wonder if this apply for records too.

I was a little skeptical. Inheritance is a big feature to make a general statement about throwing it away. But interfaces exist, so having most classes sealed and interfaces available could give the performance boost of sealed while allowing for people to make their own API compatible classes. The main concern is that if something is missed and there isn't an interface or some other way to customize that part of the API and the relevant class is sealed then some dev somewhere is gonna break out reflection and do some sketchy hacks to get around it.

Great video Nick. I enjoyed seeing the performance gain metrics which were a far greater magnitude than I'd thought they would be. I've been sealing classes as a default behaviour for years and it never causes me a problem. I see some comments here about how it affects testing such classes in legacy scenarios - if you are designing the sealed classes you write today correctly, they won't cause you a problem "tomorrow" when they are considered legacy. Sure, you can't control and may swear about legacy classes that are marked as sealed, cause side effects, and have no obvious extension points, but that's not a reason to not use the sealed keyword on our own classes that we can design to be "open to extension, closed to modification" (and if we're claiming we observe the SOLID principles, then the sealed keyword is non-negotiable for the O principle.) As well as ensure that dependencies are still swappable on sealed classes (settable properties, or via the ctor), delegate methods are your friend here, allowing you to swap out expensive behaviours in a test context.

Being someone who was integrating with legacy systems, "sealed" key word on public classes is most hated of them all for me - you just can't predict all the future of your system, so I would advice some humbleness on deciding what is something designed for. I know this is a bit of edge case and you can always use reflection, but still: I don't think we should focus on millisecond performance improvements when everywhere I look I see suboptimal algorithms, ridiculous data structures or architectural concepts that are pointless or harmful. And those I mentioned here are not even there as a trade off for readability or performance - quite the opposite in fact. Don't get me wrong, I praise developers of those legacy systems for domain specific device handling and such (that's why we were still using them), but you just can predict everything or you can just make a mistake of mixing few things that should be separate by accident.

Where do you got .NET7-RC2, on the download page I see the latest preview7 as the latest available for download?

Those example int method numbers: Ah, I see you're a man of culture as well :D

thanks Nick, great information.

Thank you for your videos. This is very useful for me.

I see the performance differences, but isn't it better, when other people can inherit from your code and add/customise it to their needs?

Hi Nick, thanks! I didn’t expect sealed to make such a difference. Any chance of the analyzer being released to older versions than .net core 7?

So... we're using OOP to extend things in a standard way. And then we need to make sure we apply a keyword by default to disable it, so we get some performance back. I see...

Inheritance isn't an anti pattern. People (i.e. inexperienced programmers) just tend to use inherence incorrectly i.e. behaviour reuse instead of to establish type relationships. The reason it's not sealed by default is that that its correct use is more common than the want to protect against it so you would in normal use be spending more time adding "unsealed" to everything than you would be doing the contrary. Despite the performance benefits. If you don't believe me just look at the extent of inheritance in the .NET framework itself.

@Nick Chapsas what about public class XXXController : ControllerBase in web api?

5:50 this is nonsense, I'm not sure if you talk about this in other videos. The fastest measureable time in theory is one CPU cycle. For a modern 5GHz machine that would be 0.2ns (you, too, have a 4.9 GHz processor). If the benchmark returns a value smaller than this, there's a measuring problem and indeed, dotnet benchmark also warns you about this right below the table, in red: "This method duration is indistinguishable from the empty method duration" and further more, the median is 0ns, which means, half of the benchmarked values were 0ns. So "1000times faster" is nonsense. To measure super fast code you can not purely rely on the benchmark framework. It's a bit tricky. You might need multiple evaluations in the benchmarking function. The benchmark values always contain a bit of noise. The OpenVoid method takes 1 CPU cycle and the OpenInt method takes 4 CPU cycles. So you cannot be faster than openvoid because you cannot be faster than 1 CPU cycle.

Actualy, 0.0008ns would be 800 femtoseconds. That is many times faster than any CPU could execute any instruction. It must be just completely optimized away.

I avoid inheritance like the plage. I inherited (no pun intended) a project in 2010 where the previous developers made the mistake of relying heavily on inheritance, and it was an absolute pain to work with.

Eye opening video. Is same is true for sealed method ?

I think right now it's needed to be included into linters warnings by default like "The class %ClassName% is not inherited anywhere and can be made sealed". Is there any suggestion for this on JetBrains YouTrack?

Awesome man!!!

From time to time it happens that you want to bend some library to your will or to intercept some internal state (by assuming full responsibility that it could break in the future!) and usually it would be impossible with sealed by default. Strictly from a crafty developer UX perspective - I despise sealed classes. I vote - no :)

I agree with the point that they should be sealed by default. Much like declaring public.

I feel like many things, like Sealed being the default, could be changed, similar to NRT(Nullable Reference Types) - by adding a setting in the .csproj file. true true // This is currently not even a feature, but it hopefully will come soon.. and then potentially add a wrapper tag: 2022 // This would then set all the default values (like NRT to enabled, both of the preceding values to true, and so on..) C# is an aging language and has a lot of flawed design decisions. I feel like, at some point, this needs some way of being addressed. Why do we, in 2022, have to live with poor design decisions made in early 2000s when we don't run _any_ code from that era?

The performance benefits also seem to apply (not fully though) for an "open" class that uses sealed override methods. (public sealed override ExampleVoidMethod() { })

Great video, as usual. One point I noticed in your tutorial (and Stevens issue) is that both the sealed class and the open class are themselves inheriting from a base class. Would the same hold true if both of these classes were not explicitly inheriting another class?

Great video.

AWESOME content! Do this rule of sealed classes also work for the old .NET Framework? Is there a gain in performance there as well?

Seems like the performance gain could be a compiler optimization without having to seal classes manually. If there are no extensions of the class, the compiler should be able to know that.

Hi nick, pls consider design patterns also in upcoming videos. Mainly DDD and eventsourcing. And whats ur opinion on aggregate roots

Great video, thank you! I expect there would be a lot of comments from people who oppose sealing everything :D

Any good talks/examples on "composition over inheritance"?

It is easier for a new language to comment on something that's been there for many years in an existing language. This might be true that sealing a class will benefit the code in terms of performance. However, it is not the case when you did not have such long historical development in the past. No one would design a language that will be perfect forever. Otherwise, people won't come up a new language every few years. I don't want to think this is a "design flaw" of C#. If it were a design flaw, it would be caught back then already. Any obvious flaw would be resolved at the beginning. The fact it existed and people did not feel wrong about it for many years indicates it is indeed ok in most cases. If thinking about today's programming world, lots of things have been changed comparing to 10 or 20 years ago. More micro apps were built, more services built behind API. People are not really depending on SDK, rather more dependency on common agreement such as interface like JSON - which is loosely bound between 2 sides (client & server). You don't really need to inherit a class in order to consume that service anymore. The rapid development around the web/service technology enables us to jump out of the scope of language itself. When coming to a system design, it is common to write code in language A to call another service written in language B. There is really not much of need to inherit the class anymore. However, when you really need to get hands on a particular language's SDK, most likely you DO WANT TO extend the classes from it, hence the "inheritence" of OOP is assumed by default. I am not saying "sealing a class by default" is wrong, but changing the default from "not sealing" to "sealing" isn't obsolutely the right decision either, at least that is my opinion.

I swear, I don't know if it's your channel or .NET people in general, but this obsession over performance all the time... The only good reason to seal classes is because you didn't design them to be inherited anyway. To which I agree, sealed should be the default.

If anyone else might consume your code, PLEASE DON'T seal public classes by default! Sealing public classes that get consumed by other devs basically says "F#@$ Y0U, I DON'T CARE ABOUT WHAT YOU WANT TO DO" I have had multiple times where I've had to waste time writing a bunch of wrapper code for a sealed class because the author of the class thought that it should be sealed since they never considered my use case. API writers don't need to support other developers' code that inherits from their class. But they need to let other developers do their jobs without artificially limiting what they can do. Developers know that if they write code that breaks things, then it is their own fault. Don't try to "save" future developers from possibly causing a bug. That said, if you NEED the performance, or if you know that your only consumers are people in your same organization that you can unseal the class when asked, go right ahead and seal everything. Seal internal objects. But, DON'T STRIP FUTURE DEVELOPERS OF THE TOOLS TO DO THEIR JOBS. Inheritance is a programming tool, and disabling it by default is BAD.

Holup. 0.0008 nanoseconds? 800 _femtoseconds_? I'm pretty sure home computers can't even measure timespans that short. That's a tiny, tiny fraction of even a single clock cycle. I'm much more inclined to think that it's a threshold artifact. That is, most of the operations were below the minimum timespan to measure and reported as effectively zero, which got averaged up to some crazy small value by the occasional 1 ns measurement. Whereas the inheritable class tests had a much greater fraction of tests come out to 1ns, dragging the average higher. It's like if you take the average of each these values, but first treating anything below 0.5 as 0 0.4, 0.3, 0.4, 0.6, 0.4, 0.5, 0.4 => 0.16, which is lower than any of the actual reported values. vs bumping up each value by just 0.1, again treating anything below 0.5 as zero first 0.5, 0.4, 0.5, 0.7, 0.5, 0.6, 0.5 => 0.47, seemingly tripling the average, even though the inputs didn't increase anywhere near that much. Yeah, look at the SealedInt median value @6:36: 0ns. You'd only get that if the majority of the values were zero, which cannot accurately reflect the true computing time. Can you do an aggregate measurement of a million of each instantiation, rather than trying to time each and every one separately?

How about static classes vs internal, sealed, private ?

Hey Nick, I love this video and agree in 'general', but I see one glaring side affect: Mocking...when a class is sealed, I can't mock it. I can extract an interface, inherit, and then so long as I'm careful to ALWAYS use interfaces, all is well again (and in general, I use a lot of dependency injection and use interfaces, etc.) I worry though that the framework may not allow that...and being able to mock things is quite important...thoughts?

Would be better if Microsoft worked on internal performance of sealed vs not sealed classes instead of making developers adding an extra word to each class.