He encontrado muchos consejos de optimización que dicen que debes marcar tus clases como selladas para obtener beneficios de rendimiento adicionales.

Ejecuté algunas pruebas para verificar el diferencial de rendimiento y no encontré ninguna. ¿Estoy haciendo algo mal? ¿Me estoy perdiendo el caso en que las clases selladas darán mejores resultados?

¿Alguien ha realizado pruebas y ha visto una diferencia?

Ayudame a aprender :)

El JITter a veces usará llamadas no virtuales a métodos en clases selladas ya que no hay forma de que puedan extenderse más.

Existen reglas complejas con respecto al tipo de llamada, virtual / no virtual, y no las conozco todas, así que realmente no puedo describirlas para usted, pero si busca en Google clases selladas y métodos virtuales, puede encontrar algunos artículos sobre el tema.

Tenga en cuenta que cualquier tipo de beneficio de rendimiento que obtenga de este nivel de optimización debe considerarse como último recurso, siempre optimice en el nivel algorítmico antes de optimizar en el nivel de código.

Aquí hay un enlace que menciona esto: divagando sobre la palabra clave sellada

La respuesta es no, las clases selladas no funcionan mejor que las no selladas.

El problema se reduce a los códigos operativos callvs callvirtIL. Calles más rápido que callvirt, y callvirtse usa principalmente cuando no sabes si el objeto ha sido subclasificado. Entonces la gente supone que si sella una clase, todos los códigos de operación cambiarán de calvirtsa callsy serán más rápidos.

Desafortunadamente callvirt, también hay otras cosas que lo hacen útil, como buscar referencias nulas. Esto significa que incluso si una clase está sellada, la referencia podría ser nula y, por lo tanto, callvirtse necesita a. Puede evitar esto (sin necesidad de sellar la clase), pero se vuelve un poco inútil.

Las estructuras se usan callporque no pueden subclasificarse y nunca son nulas.

Vea esta pregunta para más información:

Llamada y callvirt

Actualización: a partir de .NET Core 2.0 y .NET Desktop 4.7.1, el CLR ahora admite la desvirtualización. Puede tomar métodos en clases selladas y reemplazar llamadas virtuales con llamadas directas, y también puede hacerlo para clases no selladas si puede descubrir que es seguro hacerlo.

En tal caso (una clase sellada que el CLR no podría detectar como seguro para desvirtualizar), una clase sellada debería ofrecer algún tipo de beneficio de rendimiento.

Dicho esto, no creo que valga la pena preocuparse a menos que ya haya perfilado el código y haya determinado que estaba en una ruta particularmente caliente que se llamaba millones de veces, o algo así:

https://blogs.msdn.microsoft.com/dotnet/2017/06/29/performance-improvements-in-ryujit-in-net-core-and-net-framework/

Respuesta original

Hice el siguiente programa de prueba y luego lo descomprimí usando Reflector para ver qué código MSIL se emitió.

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

En todos los casos, el compilador de C # (Visual studio 2010 en la configuración de la versión de lanzamiento) emite MSIL idéntico, que es el siguiente:

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 

La razón citada a menudo por la cual las personas dicen que el sellado proporciona beneficios de rendimiento es que el compilador sabe que la clase no se anula y, por lo tanto, puede usarla en calllugar de callvirtno tener que buscar virtuales, etc. Como se demostró anteriormente, esto no es cierto.

Mi siguiente pensamiento fue que, aunque el MSIL es idéntico, ¿quizás el compilador JIT trata las clases selladas de manera diferente?

Ejecuté una versión de lanzamiento bajo el depurador visual studio y vi la salida x86 descompilada. En ambos casos, el código x86 era idéntico, con la excepción de los nombres de clase y las direcciones de memoria de funciones (que, por supuesto, deben ser diferentes). Aquí está

//            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 

Entonces pensé que tal vez correr bajo el depurador hace que realice una optimización menos agresiva.

Luego ejecuté un ejecutable de compilación de versión independiente fuera de cualquier entorno de depuración, y usé WinDBG + SOS para entrar después de que el programa se había completado, y ver el desensamblaje del código x86 compilado JIT.

Como puede ver en el siguiente código, cuando se ejecuta fuera del depurador, el compilador JIT es más agresivo y ha incorporado el WriteItmétodo directamente a la persona que llama. Sin embargo, lo crucial es que era idéntico al llamar a una clase sellada frente a una no sellada. No hay diferencia alguna entre una clase sellada o no sellada.

Aquí es cuando se llama a una clase normal:

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

Vs una clase sellada:

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

Para mí, esto proporciona una prueba sólida de que no puede haber ninguna mejora en el rendimiento entre los métodos de llamada en clases selladas frente a no selladas ... Creo que estoy contento ahora :-)

Como sé, no hay garantía de beneficio de rendimiento. Pero existe la posibilidad de disminuir la penalización de rendimiento bajo alguna condición específica con un método sellado. (la clase sellada hace que todos los métodos sean sellados).

Pero depende del entorno de implementación y ejecución del compilador.

Detalles

Muchas de las CPU modernas usan una estructura de tubería larga para aumentar el rendimiento. Debido a que la CPU es increíblemente más rápida que la memoria, la CPU tiene que buscar previamente el código de la memoria para acelerar la canalización. Si el código no está listo en el momento adecuado, las tuberías estarán inactivas.

Hay un gran obstáculo llamado despacho dinámico que interrumpe esta optimización de 'captación previa'. Puedes entender esto solo como una ramificación condicional.

// 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();

La CPU no puede buscar previamente el siguiente código para ejecutar en este caso porque la siguiente posición del código es desconocida hasta que se resuelva la condición. Esto hace que el peligro provoque que la tubería esté inactiva. Y la penalización de rendimiento por inactividad es enorme en regular.

Algo similar sucede en caso de anulación del método. El compilador puede determinar la anulación del método adecuado para la llamada al método actual, pero a veces es imposible. En este caso, el método adecuado solo se puede determinar en tiempo de ejecución. Este también es un caso de despacho dinámico, y, una razón principal de los lenguajes de tipo dinámico son generalmente más lentos que los idiomas de tipo estático.

Algunas CPU (incluidos los recientes chips x86 de Intel) utilizan una técnica llamada ejecución especulativa para utilizar la canalización incluso en la situación. Simplemente busque una ruta de ejecución. Pero la tasa de éxito de esta técnica no es tan alta. Y la falla de la especulación provoca el estancamiento de la tubería, lo que también genera una gran penalización de rendimiento. (Esto es completamente por la implementación de la CPU. Algunas CPU móviles se conocen como no este tipo de optimización para ahorrar energía)

Básicamente, C # es un lenguaje compilado estáticamente. Pero no siempre. No sé la condición exacta y esto depende completamente de la implementación del compilador. Algunos compiladores pueden eliminar la posibilidad de envío dinámico al evitar la anulación del método si el método está marcado como sealed. Estúpidos compiladores no pueden. Este es el beneficio de rendimiento de la sealed.

Esta respuesta ( ¿Por qué es más rápido procesar una matriz ordenada que una matriz no clasificada? ) Describe la predicción de ramificación mucho mejor.

<off-topic-rant>

Yo detesto clases cerradas. Incluso si los beneficios de rendimiento son asombrosos (lo cual dudo), destruyen el modelo orientado a objetos al evitar la reutilización por herencia. Por ejemplo, la clase Thread está sellada. Si bien puedo ver que uno podría querer que los subprocesos sean lo más eficientes posible, también puedo imaginar escenarios en los que poder subclasificar subprocesos tendría grandes beneficios. Autores de la clase, si debe sellar sus clases por razones de "rendimiento", proporcione una interfaz como mínimo para que no tengamos que ajustar y reemplazar en todos los lugares en los que necesitemos una función que haya olvidado.

Ejemplo: SafeThread tuvo que ajustar la clase Thread porque Thread está sellado y no hay una interfaz IThread; SafeThread atrapa automáticamente las excepciones no controladas en los subprocesos, algo que falta por completo en la clase Thread. [y no, los eventos de excepción no controlados no recogen excepciones no controladas en subprocesos secundarios].

</off-topic-rant>

Marcar una clase no sealeddebería tener impacto en el rendimiento.

Hay casos en los que cscpodría tener que emitir un callvirtcódigo de operación en lugar de un callcódigo de operación. Sin embargo, parece que esos casos son raros.

Y me parece que el JIT debería poder emitir la misma llamada de función no virtual para la callvirtque lo haría call, si sabe que la clase no tiene ninguna subclase (todavía). Si solo existe una implementación del método, no tiene sentido cargar su dirección desde una vtable, solo llame a la implementación directamente. Para el caso, el JIT puede incluso en línea la función.

Es una especie de apuesta por parte del JIT, porque si una subclase se carga más tarde, el JIT tendrá que tirar ese código de máquina y compilar el código nuevamente, emitiendo una llamada virtual real. Supongo que esto no sucede a menudo en la práctica.

(Y sí, los diseñadores de VM realmente persiguen agresivamente estas pequeñas victorias de rendimiento).

Las clases selladas deberían proporcionar una mejora del rendimiento. Dado que no se puede derivar una clase sellada, cualquier miembro virtual puede convertirse en miembros no virtuales.

Por supuesto, estamos hablando de ganancias muy pequeñas. No marcaría una clase como sellada solo para obtener una mejora en el rendimiento a menos que el perfil revelara que es un problema.

Considero que las clases "selladas" son el caso normal y SIEMPRE tengo una razón para omitir la palabra clave "sellada".

Las razones más importantes para mí son:

a) Mejores comprobaciones en tiempo de compilación (la detección de interfaces no implementadas se detectará en tiempo de compilación, no solo en tiempo de ejecución)

y, razón principal:

b) El abuso de mis clases no es posible de esa manera.

Desearía que Microsoft hubiera hecho "sellado" el estándar, no "sin sellar".

@ Vaibhav, ¿qué tipo de pruebas ejecutó para medir el rendimiento?

Supongo que uno tendría que usar Rotor y profundizar en CLI y comprender cómo una clase sellada mejoraría el rendimiento.

SSCLI (Rotor)
SSCLI: Infraestructura de lenguaje común de fuente compartida

Common Language Infrastructure (CLI) es el estándar ECMA que describe el núcleo de .NET Framework. Shared Source CLI (SSCLI), también conocido como Rotor, es un archivo comprimido del código fuente para una implementación funcional de ECMA CLI y la especificación de lenguaje ECMA C #, tecnologías en el corazón de la arquitectura .NET de Microsoft.

las clases selladas serán al menos un poco más rápidas, pero a veces pueden ser mucho más rápidas ... si el JIT Optimizer puede hacer llamadas en línea que de otra forma habrían sido llamadas virtuales. Entonces, donde hay métodos que a menudo son lo suficientemente pequeños como para estar en línea, definitivamente considere sellar la clase.

Sin embargo, la mejor razón para sellar una clase es decir "No diseñé esto para heredarlo, así que no voy a dejar que te quemes, suponiendo que fue diseñado para ser así, y no voy a ir para quemarme encerrado en una implementación porque te dejo derivar de ella ".

Sé que algunos aquí han dicho que odian las clases selladas porque quieren la oportunidad de derivar de cualquier cosa ... pero esa NO ES LA OPCIÓN MÁS DURADERA ... porque exponer una clase a la derivación te bloquea mucho más que no exponer todo ese. Es similar a decir "Odio las clases que tienen miembros privados ... A menudo no puedo hacer que la clase haga lo que quiero porque no tengo acceso". La encapsulación es importante ... el sellado es una forma de encapsulación.

Para verlos realmente es necesario analizar el código e compilado JIT (último).

Código 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();
}

Código 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

Código Compilado 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  

Si bien la creación de los objetos es la misma, las instrucciones ejecutadas para invocar los métodos de la clase sellada y derivada / base son ligeramente diferentes. Después de mover datos a registros o RAM (instrucción mov), la invocación del método sellado, ejecuta una comparación entre dword ptr [ecx], ecx (instrucción cmp) y luego llama al método mientras la clase derivada / base ejecuta directamente el método. .

Según el informe escrito por Torbj¨orn Granlund, latencias de instrucción y rendimiento para procesadores AMD e Intel x86 , la velocidad de las siguientes instrucciones en un Intel Pentium 4 son:

• mov : tiene 1 ciclo como latencia y el procesador puede soportar 2.5 instrucciones por ciclo de este tipo
• cmp : tiene 1 ciclo como latencia y el procesador puede soportar 2 instrucciones por ciclo de este tipo

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

Esto significa que, idealmente , el tiempo necesario para invocar un método sellado es de 2 ciclos, mientras que el tiempo necesario para invocar un método derivado o de clase base es de 3 ciclos.

La optimización de los compiladores ha marcado la diferencia entre el rendimiento de una clase sellada y no sellada tan baja que estamos hablando de círculos de procesadores y por esta razón son irrelevantes para la mayoría de las aplicaciones.

Ejecute este código y verá que las clases selladas son 2 veces más rápidas:

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

salida: clase sellada: 00: 00: 00.1897568 clase no sellada: 00: 00: 00.3826678