Vai*_*hav 134 .net optimization performance frameworks
我遇到了很多优化提示,说明你应该将你的课程标记为密封以获得额外的性能优势.
我运行了一些测试以检查性能差异,但没有找到.难道我做错了什么？我错过了密封课程会给出更好结果的情况吗？
有没有人进行测试并看到了差异？
帮我学习:)
Cam*_*and 138
答案是否定的,密封类的表现不如非密封.
问题归结为callvs callvirtIL操作码.Call比您更快callvirt,并且callvirt主要在您不知道对象是否已被子类化时使用.因此人们认为,如果你密封一个班级,所有的操作码将会改变calvirts,calls并且会更快.
不幸的是callvirt,其他使它也有用的东西,比如检查空引用.这意味着即使密封了类,引用仍可能为null,因此callvirt需要a.你可以绕过这个(不需要密封课程),但它变得有点无意义.
结构使用call是因为它们不能被子类化并且永远不会为空.
有关更多信息,请参阅此问题:
ang*_*son 56
JITter有时会对密封类中的方法使用非虚拟调用,因为它们无法进一步扩展.
有关于呼叫类型,虚拟/非虚拟的复杂规则,我不知道所有这些,所以我无法为你概述它们,但如果你谷歌的密封类和虚拟方法,你可能会发现有关该主题的一些文章.
请注意,从这种优化级别获得的任何性能优势都应视为最后的手段,在优化代码级别之前始终优化算法级别.
这里有一个提到这个的链接:密封关键字
Ori*_*rds 25
更新:从.NET Core 2.0和.NET Desktop 4.7.1开始,CLR现在支持虚拟化.它可以采用密封类中的方法,并使用直接调用替换虚拟调用 - 如果它可以确定安全,也可以对非密封类执行此操作.
在这种情况下(CLR无法检测到的密封类可以安全地进行虚拟化),密封类实际上应该提供某种性能优势.
也就是说,我不认为值得担心,除非你已经对代码进行了描述并确定你处于被称为数百万次的特别热门的道路,或类似的东西:
原答案:
我制作了以下测试程序,然后使用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编译器对密封类的处理方式不同？
我在visual studio调试器下运行了一个发布版本,并查看了反编译的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中断,并查看JIT编译的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
对我来说,这提供了坚实的证据,证明在密封类和非密封类之间的调用方法之间不会有任何性能改进......我想我现在很开心:-)
Eon*_*nil 23
据我所知,无法保证性能优势.但是在密封方法的某些特定条件下,有可能降低性能损失.(密封等级使所有方法都被密封.)
但这取决于编译器实现和执行环境.
许多现代CPU使用长管道结构来提高性能.由于CPU比内存快得多,因此CPU必须从内存中预取代码以加速管道.如果代码在适当的时候没有准备好,则管道将处于空闲状态.
有一个很大的障碍称为动态调度,这会破坏这种"预取"优化.您可以将其理解为条件分支.
// Value of `v` is unknown,
// and can be resolved only at runtime.
// CPU cannot know which code to prefetch.
// Therefore, just prefetch any one of a() or b().
// This is *speculative execution*.
int v = random();
if (v==1) a();
else b();
在这种情况下,CPU无法预取下一个要执行的代码,因为在条件解决之前,下一个代码位置是未知的.所以这会导致危险导致管道闲置.而闲置的性能损失在常规中是巨大的.
在方法重写的情况下会发生类似的事情.编译器可以确定当前方法调用的正确方法覆盖,但有时这是不可能的.在这种情况下,只能在运行时确定适当的方法.这也是动态调度的一种情况,动态类型语言的主要原因通常比静态类型语言慢.
一些CPU(包括最近的英特尔x86芯片)使用称为推测执行的技术来利用管道即使在这种情况下也是如此.只需预取一个执行路径.但是这种技术的命中率并不高.而推测失败会导致管道停滞,这也会造成巨大的性能损失.(这完全是由CPU实现的.一些移动CPU被称为没有这种节省能源的优化)
基本上,C#是一种静态编译的语言.但不总是.我不知道确切的条件,这完全取决于编译器的实现.如果方法被标记为,则某些编译器可以通过阻止方法覆盖来消除动态分派的可能性sealed.愚蠢的编译器可能不会.这是性能的好处sealed.
这个答案(为什么处理排序数组比处理未排序数组更快？)更好地描述了分支预测.
<题外话>
我讨厌密封的课程。即使性能优势令人震惊（我对此表示怀疑），它们也会通过继承阻止重用来破坏面向对象的模型。例如，Thread 类是密封的。虽然我可以看到人们可能希望线程尽可能高效，但我也可以想象能够对 Thread 进行子类化会带来很大好处的场景。类作者，如果您出于“性能”原因必须密封您的类，请至少提供一个接口，这样我们就不必在需要您忘记的功能的任何地方进行包装和替换。
示例：SafeThread不得不将 Thread 类包装起来，因为 Thread 是密封的，没有 IThread 接口；SafeThread 自动捕获线程上未处理的异常，这是 Thread 类中完全缺失的。[不，未处理的异常事件不会在辅助线程中拾取未处理的异常]。
</off-topic-rant>