Оновлення: Станом на .NET Core 2.0 та .NET Desktop 4.7.1, CLR тепер підтримує девіартуалізацію. Він може приймати методи в закритих класах і замінювати віртуальні дзвінки прямими дзвінками - і він також може робити це для незапечатаних класів, якщо зможе зрозуміти, що це безпечно.
У такому випадку (герметичний клас, який CLR інакше не міг визначити безпечним для девіатуризації), герметичний клас повинен фактично запропонувати певну користь від продуктивності.
З цього приводу я не думаю, що варто було б турбуватися про те, якщо ви вже не профайлювали код і не визначили, що потрапляєте в особливо гарячий шлях, який вас називають мільйони разів, або щось подібне:
https://blogs.msdn.microsoft.com/dotnet/2017/06/29/performance-improvements-in-ryujit-in-net-core-and-net-framework/
Оригінальний відповідь:
Я зробив наступну програму тестування, а потім декомпілював її за допомогою Reflector, щоб побачити, який код MSIL випромінюється.
public class NormalClass {
public void WriteIt(string x) {
Console.WriteLine("NormalClass");
Console.WriteLine(x);
}
}
public sealed class SealedClass {
public void WriteIt(string x) {
Console.WriteLine("SealedClass");
Console.WriteLine(x);
}
}
public static void CallNormal() {
var n = new NormalClass();
n.WriteIt("a string");
}
public static void CallSealed() {
var n = new SealedClass();
n.WriteIt("a string");
}
У всіх випадках компілятор C # (Visual studio 2010 у конфігурації збірки випусків) випускає ідентичний MSIL, який є наступним:
L_0000: newobj instance void <NormalClass or SealedClass>::.ctor()
L_0005: stloc.0
L_0006: ldloc.0
L_0007: ldstr "a string"
L_000c: callvirt instance void <NormalClass or SealedClass>::WriteIt(string)
L_0011: ret
Часто цитується причина, за якою люди кажуть, що запечатаний приносить переваги продуктивності - це те, що компілятор знає, що клас не перекрито, і тому він може використовувати callзамість того callvirt, що він не повинен перевіряти віртуальність тощо. Як було доведено вище, це не так правда.
Наступна моя думка полягала в тому, що, хоча MSIL ідентичний, можливо, компілятор JIT трактує класи, запечатані по-різному?
Я провів збірку релізів під налагоджувачем візуальної студії та переглянув розкладений вихід x86. В обох випадках код x86 був ідентичним, за винятком імен класів та адрес пам'яті функцій (які, звичайно, повинні бути різними). Ось
// var n = new NormalClass();
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,8
00000006 cmp dword ptr ds:[00585314h],0
0000000d je 00000014
0000000f call 70032C33
00000014 xor edx,edx
00000016 mov dword ptr [ebp-4],edx
00000019 mov ecx,588230h
0000001e call FFEEEBC0
00000023 mov dword ptr [ebp-8],eax
00000026 mov ecx,dword ptr [ebp-8]
00000029 call dword ptr ds:[00588260h]
0000002f mov eax,dword ptr [ebp-8]
00000032 mov dword ptr [ebp-4],eax
// n.WriteIt("a string");
00000035 mov edx,dword ptr ds:[033220DCh]
0000003b mov ecx,dword ptr [ebp-4]
0000003e cmp dword ptr [ecx],ecx
00000040 call dword ptr ds:[0058827Ch]
// }
00000046 nop
00000047 mov esp,ebp
00000049 pop ebp
0000004a ret
Тоді я думав, що, можливо, робота під налагоджувачем призводить до менш агресивної оптимізації?
Потім я запустив автономну версію збірки версій за межами будь-яких середовищ налагодження та використав WinDBG + SOS для прориву після завершення програми та перегляду розбирання компільованого кодом x86 x86.
Як видно з коду нижче, при запуску поза налагоджувачем компілятор JIT є більш агресивним, і він вклав WriteItметод прямо в абонент. Найважливішим, однак, є те, що він був ідентичним під час виклику запечатаного проти незапечатаного класу. Немає різниці між герметичним або незапечатаним класом.
Ось це під час виклику звичайного класу:
Normal JIT generated code
Begin 003c00b0, size 39
003c00b0 55 push ebp
003c00b1 8bec mov ebp,esp
003c00b3 b994391800 mov ecx,183994h (MT: ScratchConsoleApplicationFX4.NormalClass)
003c00b8 e8631fdbff call 00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c00bd e80e70106f call mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00c2 8bc8 mov ecx,eax
003c00c4 8b1530203003 mov edx,dword ptr ds:[3302030h] ("NormalClass")
003c00ca 8b01 mov eax,dword ptr [ecx]
003c00cc 8b403c mov eax,dword ptr [eax+3Ch]
003c00cf ff5010 call dword ptr [eax+10h]
003c00d2 e8f96f106f call mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c00d7 8bc8 mov ecx,eax
003c00d9 8b1534203003 mov edx,dword ptr ds:[3302034h] ("a string")
003c00df 8b01 mov eax,dword ptr [ecx]
003c00e1 8b403c mov eax,dword ptr [eax+3Ch]
003c00e4 ff5010 call dword ptr [eax+10h]
003c00e7 5d pop ebp
003c00e8 c3 ret
Проти запечатаного класу:
Normal JIT generated code
Begin 003c0100, size 39
003c0100 55 push ebp
003c0101 8bec mov ebp,esp
003c0103 b90c3a1800 mov ecx,183A0Ch (MT: ScratchConsoleApplicationFX4.SealedClass)
003c0108 e8131fdbff call 00172020 (JitHelp: CORINFO_HELP_NEWSFAST)
003c010d e8be6f106f call mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0112 8bc8 mov ecx,eax
003c0114 8b1538203003 mov edx,dword ptr ds:[3302038h] ("SealedClass")
003c011a 8b01 mov eax,dword ptr [ecx]
003c011c 8b403c mov eax,dword ptr [eax+3Ch]
003c011f ff5010 call dword ptr [eax+10h]
003c0122 e8a96f106f call mscorlib_ni+0x2570d0 (6f4c70d0) (System.Console.get_Out(), mdToken: 060008fd)
003c0127 8bc8 mov ecx,eax
003c0129 8b1534203003 mov edx,dword ptr ds:[3302034h] ("a string")
003c012f 8b01 mov eax,dword ptr [ecx]
003c0131 8b403c mov eax,dword ptr [eax+3Ch]
003c0134 ff5010 call dword ptr [eax+10h]
003c0137 5d pop ebp
003c0138 c3 ret
Для мене це є надійним доказом того, що між методами виклику на закритих та незапечатаних класах не може бути покращено продуктивність ... Я думаю, що я щасливий зараз :-)