I have come across a lot of optimization tips which say that you should mark your classes as sealed to get extra performance benefits.
I ran some tests to check the performance differential and found none. Am I doing something wrong? Am I missing the case where sealed classes will give better results?
Has anyone run tests and seen a difference?
Help me learn :)
Well yes, that is the functional purpose of marking a class sealed. But I have read that there is a performance benefit to them as well, and that is what I have been trying to explore.
The JITter will sometimes use non-virtual calls to methods in sealed classes since there is no way they can be extended further.
There are complex rules regarding calling type, virtual/nonvirtual, and I don't know them all so I can't really outline them for you, but if you google for sealed classes and virtual methods you might find some articles on the topic.
Note that any kind of performance benefit you would obtain from this level of optimization should be regarded as last-resort, always optimize on the algorithmic level before you optimize on the code-level.
Here's one link mentioning this: Rambling on the sealed keyword
Sealed classes should provide a performance improvement. Since a sealed class cannot be derived, any virtual members can be turned into non-virtual members.
Of course, we're talking really small gains. I wouldn't mark a class as sealed just to get a performance improvement unless profiling revealed it to be a problem.
@lassevk Yup, I googled and googled... And what you mentioned is exactly what I got. Nowhere have I found an exact answer which says in which situations something like this can be helpful.
I mean, I did try creating class structures with inheritance and virtual methods, and all that. But, still not difference in performance.
So, either I discard the claim I see at so many places that this optimized performance (which I don't want to do since it has been made by people smarter than I am), or I search till my thirsty soul is quenched by knowledge.
So, the question is still open. Has anyone worked numbers on this? And does anyone know what are the exact situations where this applies?
Thanks.
@Vaibhav, what kind of tests did you execute to measure performance?
I guess one would have to use Rotor and to drill into CLI and understand how a sealed class would improve performance.
SSCLI (Rotor)
SSCLI: Shared Source Common Language InfrastructureThe Common Language Infrastructure (CLI) is the ECMA standard that describes the core of the .NET Framework. The Shared Source CLI (SSCLI), also known as Rotor, is a compressed archive of the source code to a working implementation of the ECMA CLI and the ECMA C# language specification, technologies at the heart of Microsoft’s .NET architecture.
The test included creating a class hierarchy, with some methods which were doing dummy work (string manipulation mostly). Some of these methods were virtual. They were calling each other here and there.
Then calling these methods 100, 10000, and 100000 times... and measuring the time elapsed.
Then running these after marking the classes as sealed. and measuring again.
No difference in them.
<off-topic-rant>
I loathe sealed classes. Even if the performance benefits are astounding (which I doubt), they destroy the object-oriented model by preventing reuse via inheritance. For example, the Thread class is sealed. While I can see that one might want threads to be as efficient as possible, I can also imagine scenarios where being able to subclass Thread would have great benefits. Class authors, if you must seal your classes for "performance" reasons, please provide an interface at the very least so we don't have to wrap-and-replace everywhere that we need a feature you forgot.
Example: SafeThread had to wrap the Thread class because Thread is sealed and there is no IThread interface; SafeThread automatically traps unhandled exceptions on threads, something completely missing from the Thread class. [and no, the unhandled exception events do not pick up unhandled exceptions in secondary threads].
</off-topic-rant>
The answer is no, sealed classes do not perform better than non-sealed.
The issue comes down to the call vs callvirt IL op codes. Call is faster than callvirt, and callvirt is mainly used when you don't know if the object has been subclassed. So people assume that if you seal a class all the op codes will change from calvirts to calls and will be faster.
Unfortunately callvirt does other things that make it useful too, like checking for null references. This means that even if a class is sealed, the reference might still be null and thus a callvirt is needed. You can get around this (without needing to seal the class), but it becomes a bit pointless.
Structs use call because they cannot be subclassed and are never null.
See this question for more information:
Marking a class sealed should have no performance impact.
There are cases where csc might have to emit a callvirt opcode instead of a call opcode. However, it seems those cases are rare.
And it seems to me that the JIT should be able to emit the same non-virtual function call for callvirt that it would for call, if it knows that the class doesn't have any subclasses (yet). If only one implementation of the method exists, there's no point loading its address from a vtable—just call the one implementation directly. For that matter, the JIT can even inline the function.
It's a bit of a gamble on the JIT's part, because if a subclass is later loaded, the JIT will have to throw away that machine code and compile the code again, emitting a real virtual call. My guess is this doesn't happen often in practice.
(And yes, VM designers really do aggressively pursue these tiny performance wins.)
Run this code and you'll see that sealed classes are 2 times faster:
class Program
{
static void Main(string[] args)
{
Console.ReadLine();
var watch = new Stopwatch();
watch.Start();
for (int i = 0; i < 10000000; i++)
{
new SealedClass().GetName();
}
watch.Stop();
Console.WriteLine("Sealed class : {0}", watch.Elapsed.ToString());
watch.Start();
for (int i = 0; i < 10000000; i++)
{
new NonSealedClass().GetName();
}
watch.Stop();
Console.WriteLine("NonSealed class : {0}", watch.Elapsed.ToString());
Console.ReadKey();
}
}
sealed class SealedClass
{
public string GetName()
{
return "SealedClass";
}
}
class NonSealedClass
{
public string GetName()
{
return "NonSealedClass";
}
}
output: Sealed class : 00:00:00.1897568 NonSealed class : 00:00:00.3826678
RuslanG,
You forgot to call watch.Reset() after running first test.
o_O
:]
I consider "sealed" classes the normal case and I ALWAYS have a reason to omit the "sealed" keyword.
The most important reasons for me are:
a) Better compile time checks (casting to interfaces not implemented will be detected at compile time, not only at runtime)
and, top reason:
b) Abuse of my classes is not possible that way
I wish Microsoft would have made "sealed" the standard, not "unsealed".