密封课真的提供性能优势吗?

时间:2008-08-05 12:00:29

标签: .net optimization frameworks performance

我遇到了很多优化提示,说明你应该将你的课程标记为密封,以获得额外的性能优势。

我运行了一些测试以检查性能差异,但没有找到。难道我做错了什么?我错过了密封课程会给出更好结果的情况吗?

是否有人进行过测试并看到了不同之处?

帮助我学习:)

12 个答案:

答案 0 :(得分:138)

答案是否定的,密封课程的表现并不比非密封课程好。

问题归结为call vs callvirt IL操作码。 Callcallvirt快,callvirt主要用于不知道对象是否已被子类化的情况。所以人们认为,如果你封印了一个课程,所有操作代码将从calvirts更改为calls并且会更快。

不幸的是callvirt做了其他使它有用的事情,比如检查空引用。这意味着即使密封了类,引用仍可能为null,因此需要callvirt。你可以绕过这个(不需要密封课程),但它变得有点无意义。

结构使用call因为它们不能被子类化并且永远不会为空。

有关详细信息,请参阅此问题:

Call and callvirt

答案 1 :(得分:53)

JITter有时会对密封类中的方法使用非虚拟调用,因为它们无法进一步扩展。

有关于呼叫类型,虚拟/非虚拟的复杂规则,我不知道所有这些,所以我无法为你概述它们,但如果你谷歌的密封类和虚拟方法你可能会发现一些文章话题。

请注意,从优化级别获得的任何性能优势都应视为最后的优势,在优化代码级别之前始终优化算法级别。

以下是提及此问题的一个链接:Rambling on the sealed keyword

答案 2 :(得分:22)

更新:从.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编译器对密封类的处理方式不同?

我在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

对我而言,这提供了一个可靠的证据,即不能在密封类和非密封类之间调用方法之间的任何性能改进......我想我现在很开心: - )

答案 3 :(得分:22)

据我所知,无法保证性能优势。但是用密封方法有机会在某些特定情况下降低性能损失。 (密封等级使所有方法都被密封。)

但这取决于编译器实现和执行环境。


详细

许多现代CPU使用长流水线结构来提高性能。由于CPU比内存快得多,因此CPU必须从内存中预取代码以加速管道。如果代码在适当的时候没有准备就绪,那么管道将处于空闲状态。

有一个很大的障碍叫做 dynamic dispatch ,这会破坏这种“预取”优化。您可以将其理解为条件分支。

// 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无法预取下一个要执行的代码,因为在解决条件之前,下一个代码位置是未知的。所以这使得hazard导致管道空闲。而闲置对性能的影响很大。

在方法覆盖的情况下会发生类似的事情。编译器可以确定当前方法调用的正确方法覆盖,但有时候这是不可能的。在这种情况下,只能在运行时确定适当的方法。这也是动态调度的一种情况,动态类型语言的主要原因通常比静态类型语言慢。

某些CPU(包括最近的英特尔x86芯片)使用称为 speculative execution 的技术来利用管道即使在这种情况下也是如此。只需预取一个执行路径。但是这种技术的命中率并不高。而推测失败会导致管道停滞,这也会造成巨大的性能损失。 (这完全是由CPU实现的。一些移动CPU被称为没有这种节省能源的优化)

基本上,C#是一种静态编译的语言。但不总是。我不知道确切的条件,这完全取决于编译器的实现。如果方法被标记为sealed,则某些编译器可以通过阻止方法覆盖来消除动态分派的可能性。愚蠢的编译器可能不会。 这是sealed的性能优势。


这个答案(Why is it faster to process a sorted array than an unsorted array?)更好地描述了分支预测。

答案 4 :(得分:4)

标记课程sealed应该不会对性能产生影响。

在某些情况下,csc可能必须发出callvirt操作码而不是call操作码。但是,这些案件似乎很少见。

在我看来,JIT应该能够为callvirt发出与call相同的非虚函数调用,如果它知道该类没有任何函数子类(尚)。如果只存在该方法的一个实现,那么从vtable加载其地址是没有意义的 - 只需直接调用一个实现。就此而言,JIT甚至可以内联函数。

这是JIT的一个赌博部分,因为如果稍后加载子类 ,JIT将不得不丢弃该机器代码并再次编译代码,发出真正的虚拟调用。我的猜测是,这在实践中并不经常发生。

(是的,VM设计师确实积极地追求这些微小的性能获胜。)

答案 5 :(得分:3)

&LT;题外话-咆哮&GT;

厌恶密封的课程。即使性能优势令人震惊(我怀疑),它们通过阻止通过继承重用来销毁面向对象的模型。例如,Thread类是密封的。虽然我可以看到人们可能希望线程尽可能高效,但我也可以想象能够子类化Thread的方案会带来很大的好处。 类作者,如果您必须为了“性能”原因而密封您的课程,请至少提供一个界面,以便我们无需在任何地方进行包装和替换我们需要你忘记的功能。

示例:SafeThread必须包装Thread类,因为Thread是密封的,没有IThread接口; SafeThread自动捕获线程上未处理的异常,Thread类完全缺少这些异常。 [和不,未处理的异常事件在辅助线程中拾取未处理的异常]。

&LT; /题外话-咆哮&GT;

答案 6 :(得分:3)

我认为“密封”类是正常情况,我总是有理由省略“密封”关键字。

对我来说最重要的原因是:

a)更好的编译时间检查(在编译时检测到未实现的接口,不仅在运行时检测到)

,最重要的原因:

b)不可能以这种方式滥用我的课程

我希望微软能够“密封”标准,而不是“未密封”。

答案 7 :(得分:3)

密封类应该提供性能改进。由于无法派生密封类,因此可以将任何虚拟成员转换为非虚拟成员。

当然,我们谈的是微不足道的收获。为了获得性能提升,我不会将一个类标记为密封,除非分析显示它是一个问题。

答案 8 :(得分:2)

密封的类将至少快一点,但有时可以更快地等待...如果JIT优化器可以内联调用本来是虚拟调用。所以,如果那些被称为方法的方法足够小以便内联,那么一定要考虑密封这个类。

然而,密封课程的最好理由是说“我没有设计这个是继承的,所以我不会因为假设它被设计成这样而让你被烧掉,而我”因为我让你从中获取,所以我不会因为实施而焚烧自己。“

我知道有些人说他们讨厌密封课,因为他们希望有机会从任何东西中衍生出来......但这是OFTEN不是最易于维护的选择......因为将类暴露给派生会锁定你没有揭露所有这一切。它类似于说“我厌恶拥有私人成员的课程......我经常无法让课程做我想要的,因为我无法访问。”封装很重要......封装是一种封装形式。

答案 9 :(得分:2)

@Vaibhav,您为测量绩效执行了哪些测试?

我想我必须使用Rotor并深入了解CLI并了解密封类如何提高性能。

  

SSCLI(转子)
  SSCLI:共享源公共语言基础结构

     

公共语言基础设施   (CLI)是ECMA标准   描述了.NET的核心   框架。共享源CLI   (SSCLI),也称为Rotor,是一种   压缩存档的源代码   到工作的实施   ECMA CLI和ECMA C#语言   规范,技术   微软.NET的核心   架构。

答案 10 :(得分:1)

要真正看到它们,您需要分析 JIT编译的编码 e(最后一个)。

C#代码

public sealed class Sealed
{
    public string Message { get; set; }
    public void DoStuff() { }
}
public class Derived : Base
{
    public sealed override void DoStuff() { }
}
public class Base
{
    public string Message { get; set; }
    public virtual void DoStuff() { }
}
static void Main()
{
    Sealed sealedClass = new Sealed();
    sealedClass.DoStuff();
    Derived derivedClass = new Derived();
    derivedClass.DoStuff();
    Base BaseClass = new Base();
    BaseClass.DoStuff();
}

MIL代码

.method private hidebysig static void  Main() cil managed
{
  .entrypoint
  // Code size       41 (0x29)
  .maxstack  8
  IL_0000:  newobj     instance void ConsoleApp1.Program/Sealed::.ctor()
  IL_0005:  callvirt   instance void ConsoleApp1.Program/Sealed::DoStuff()
  IL_000a:  newobj     instance void ConsoleApp1.Program/Derived::.ctor()
  IL_000f:  callvirt   instance void ConsoleApp1.Program/Base::DoStuff()
  IL_0014:  newobj     instance void ConsoleApp1.Program/Base::.ctor()
  IL_0019:  callvirt   instance void ConsoleApp1.Program/Base::DoStuff()
  IL_0028:  ret
} // end of method Program::Main

JIT编译代码

--- C:\Users\Ivan Porta\source\repos\ConsoleApp1\Program.cs --------------------
        {
0066084A  in          al,dx  
0066084B  push        edi  
0066084C  push        esi  
0066084D  push        ebx  
0066084E  sub         esp,4Ch  
00660851  lea         edi,[ebp-58h]  
00660854  mov         ecx,13h  
00660859  xor         eax,eax  
0066085B  rep stos    dword ptr es:[edi]  
0066085D  cmp         dword ptr ds:[5842F0h],0  
00660864  je          0066086B  
00660866  call        744CFAD0  
0066086B  xor         edx,edx  
0066086D  mov         dword ptr [ebp-3Ch],edx  
00660870  xor         edx,edx  
00660872  mov         dword ptr [ebp-48h],edx  
00660875  xor         edx,edx  
00660877  mov         dword ptr [ebp-44h],edx  
0066087A  xor         edx,edx  
0066087C  mov         dword ptr [ebp-40h],edx  
0066087F  nop  
            Sealed sealedClass = new Sealed();
00660880  mov         ecx,584E1Ch  
00660885  call        005730F4  
0066088A  mov         dword ptr [ebp-4Ch],eax  
0066088D  mov         ecx,dword ptr [ebp-4Ch]  
00660890  call        00660468  
00660895  mov         eax,dword ptr [ebp-4Ch]  
00660898  mov         dword ptr [ebp-3Ch],eax  
            sealedClass.DoStuff();
0066089B  mov         ecx,dword ptr [ebp-3Ch]  
0066089E  cmp         dword ptr [ecx],ecx  
006608A0  call        00660460  
006608A5  nop  
            Derived derivedClass = new Derived();
006608A6  mov         ecx,584F3Ch  
006608AB  call        005730F4  
006608B0  mov         dword ptr [ebp-50h],eax  
006608B3  mov         ecx,dword ptr [ebp-50h]  
006608B6  call        006604A8  
006608BB  mov         eax,dword ptr [ebp-50h]  
006608BE  mov         dword ptr [ebp-40h],eax  
            derivedClass.DoStuff();
006608C1  mov         ecx,dword ptr [ebp-40h]  
006608C4  mov         eax,dword ptr [ecx]  
006608C6  mov         eax,dword ptr [eax+28h]  
006608C9  call        dword ptr [eax+10h]  
006608CC  nop  
            Base BaseClass = new Base();
006608CD  mov         ecx,584EC0h  
006608D2  call        005730F4  
006608D7  mov         dword ptr [ebp-54h],eax  
006608DA  mov         ecx,dword ptr [ebp-54h]  
006608DD  call        00660490  
006608E2  mov         eax,dword ptr [ebp-54h]  
006608E5  mov         dword ptr [ebp-44h],eax  
            BaseClass.DoStuff();
006608E8  mov         ecx,dword ptr [ebp-44h]  
006608EB  mov         eax,dword ptr [ecx]  
006608ED  mov         eax,dword ptr [eax+28h]  
006608F0  call        dword ptr [eax+10h]  
006608F3  nop  
        }
0066091A  nop  
0066091B  lea         esp,[ebp-0Ch]  
0066091E  pop         ebx  
0066091F  pop         esi  
00660920  pop         edi  
00660921  pop         ebp  

00660922  ret  

虽然对象的创建是相同的,但是执行执行以调用密封和派生/基类的方法的指令略有不同。将数据移入寄存器或RAM(移动指令)后,调用密封方法,在dword ptr [ecx],ecx(cmp指令)之间执行比较,然后在派生/基类直接执行该方法的同时调用该方法。

根据TorbjörornGranlund撰写的报告, AMD和Intel x86处理器的指令等待时间和吞吐量,Intel Pentium 4中以下指令的速度为:

  • mov :具有1个周期的等待时间,处理器每个此类周期可支持2.5条指令
  • cmp :具有1个周期的延迟,处理器可以在这种类型的每个周期维持2条指令

链接https://gmplib.org/~tege/x86-timing.pdf

这意味着,理想情况下,调用密封方法所需的时间为2个周期,而调用派生或基类方法所需的时间为3个周期。

编译器的优化使密封和未密封的分类之间的性能差异变得如此之低,以至于我们谈论的是处理器界,因此与大多数应用程序无关。

答案 11 :(得分:-9)

运行此代码,您将看到密封类的速度提高了2倍:

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";
    }
}

输出: 密封等级:00:00:00.1897568 NonSealed类:00:00:00.3826678