Sorpresa de rendimiento con "as" y tipos anulables

Solo estoy revisando el capítulo 4 de C # en profundidad, que trata sobre los tipos anulables, y estoy agregando una sección sobre el uso del operador "como", que le permite escribir:

object o = ...;
int? x = o as int?;
if (x.HasValue)
{
    ... // Use x.Value in here
}

Pensé que esto era realmente bueno, y que podría mejorar el rendimiento sobre el equivalente de C # 1, usando "es" seguido de un reparto; después de todo, de esta manera solo necesitamos pedir una verificación de tipo dinámico una vez, y luego una simple verificación de valor .

Sin embargo, este no parece ser el caso. He incluido una aplicación de prueba de muestra a continuación, que básicamente suma todos los enteros dentro de una matriz de objetos, pero la matriz contiene muchas referencias nulas y referencias de cadenas, así como enteros en caja. El punto de referencia mide el código que tendría que usar en C # 1, el código que usa el operador "como", y solo por una solución LINQ. Para mi sorpresa, el código C # 1 es 20 veces más rápido en este caso, e incluso el código LINQ (que hubiera esperado que fuera más lento, dados los iteradores involucrados) supera el código "como".

¿La implementación de .NET isinstpara tipos anulables es realmente lenta? ¿Es el adicional unbox.anyque causa el problema? ¿Hay otra explicación para esto? Por el momento parece que voy a tener que incluir una advertencia contra el uso de esto en situaciones sensibles al rendimiento ...

Resultados:

Reparto: 10000000: 121
Como: 10000000: 2211
LINQ: 10000000: 2143

Código:

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i+1] = "";
            values[i+2] = 1;
        }

        FindSumWithCast(values);
        FindSumWithAs(values);
        FindSumWithLinq(values);
    }

    static void FindSumWithCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            if (o is int)
            {
                int x = (int) o;
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Cast: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }

    static void FindSumWithAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;
            if (x.HasValue)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }

    static void FindSumWithLinq(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = values.OfType<int>().Sum();
        sw.Stop();
        Console.WriteLine("LINQ: {0} : {1}", sum, 
                          (long) sw.ElapsedMilliseconds);
    }
}

Claramente, el código de máquina que el compilador JIT puede generar para el primer caso es mucho más eficiente. Una regla que realmente ayuda es que un objeto solo se puede descomprimir en una variable que tiene el mismo tipo que el valor encuadrado. Eso permite que el compilador JIT genere código muy eficiente, no se deben considerar conversiones de valores.

El es prueba de operador está fácil, basta con comprobar si el objeto no es nulo y es del tipo esperado, pero tiene un par de instrucciones de código máquina. La conversión también es fácil, el compilador JIT conoce la ubicación de los bits de valor en el objeto y los usa directamente. No se produce ninguna copia o conversión, todo el código de la máquina está en línea y toma aproximadamente una docena de instrucciones. Esto tenía que ser realmente eficiente en .NET 1.0 cuando el boxeo era común.

Casting a int? Toma mucho más trabajo. La representación del valor del entero en caja no es compatible con el diseño de memoria de Nullable<int>. Se requiere una conversión y el código es complicado debido a los posibles tipos de enumeración en caja. El compilador JIT genera una llamada a una función auxiliar CLR llamada JIT_Unbox_Nullable para hacer el trabajo. Esta es una función de propósito general para cualquier tipo de valor, hay un montón de código para verificar los tipos. Y el valor se copia. Es difícil estimar el costo ya que este código está bloqueado dentro de mscorwks.dll, pero es probable que haya cientos de instrucciones de código de máquina.

El método de extensión Linq OfType () también usa el operador is y el elenco. Sin embargo, esto es un reparto a un tipo genérico. El compilador JIT genera una llamada a una función auxiliar, JIT_Unbox () que puede realizar una conversión a un tipo de valor arbitrario. No tengo una gran explicación de por qué es tan lento como el elenco Nullable<int>, dado que debería ser necesario menos trabajo. Sospecho que ngen.exe podría causar problemas aquí.

Me parece que isinstes realmente lento en tipos anulables. En el método FindSumWithCastcambié

if (o is int)

a

if (o is int?)

que también ralentiza significativamente la ejecución. La única diferencia en IL que puedo ver es que

isinst     [mscorlib]System.Int32

se cambia a

isinst     valuetype [mscorlib]System.Nullable`1<int32>

Originalmente, esto comenzó como un comentario a la excelente respuesta de Hans Passant, pero se hizo demasiado largo, así que quiero agregar algunos bits aquí:

Primero, el asoperador C # emitirá una isinstinstrucción IL (también lo hace el isoperador). (Otra instrucción interesante es que se castclassemite cuando realiza una conversión directa y el compilador sabe que no se puede omitir la comprobación del tiempo de ejecución).

isinstEsto es lo que hace ( ECMA 335 Partition III, 4.6 ):

Formato: isinst typeTok

typeTok es un token de metadatos (a typeref, typedefo typespec), que indica la clase deseada.

Si typeTok es un tipo de valor no anulable o un tipo de parámetro genérico, se interpreta como typeTok "en caja" .

Si typeTok es un tipo anulable Nullable<T>, se interpreta como "en caja"T

Más importante:

Si el tipo real (no el tipo de seguimiento del verificador) de obj es verificador-asignable al tipo typeTok, entonces isinsttiene éxito y obj (como resultado ) se devuelve sin cambios mientras la verificación rastrea su tipo como typeTok . A diferencia de las coacciones (§1.6) y las conversiones (§3.27), isinstnunca cambia el tipo real de un objeto y conserva la identidad del objeto (ver Partición I).

Entonces, el asesino de rendimiento no es isinsten este caso, sino el adicional unbox.any. Esto no estaba claro por la respuesta de Hans, ya que solo miró el código JITed. En general, el compilador de C # emitirá un unbox.anydespués de un isinst T?(pero lo omitirá en caso de que lo haga isinst T, cuando Tes un tipo de referencia).

¿Porque hace eso? isinst T?nunca tiene el efecto que hubiera sido obvio, es decir, vuelve a T?. En cambio, todas estas instrucciones aseguran que tengas una "boxed T"que se pueda desempaquetar T?. Para obtener un real T?, aún necesitamos desempaquetar nuestro "boxed T"to T?, por lo que el compilador emite un unbox.anyafter isinst. Si lo piensas bien, esto tiene sentido porque el "formato de caja" T?es solo una "boxed T"y crear castclassy isinstrealizar la unbox sería inconsistente.

Respaldando el hallazgo de Hans con información del estándar , aquí va:

(ECMA 335 Partición III, 4.33): unbox.any

Cuando se aplica a la forma en caja de un tipo de valor, la unbox.anyinstrucción extrae el valor contenido en obj (de tipo O). (Es equivalente a unboxseguido de ldobj.) Cuando se aplica a un tipo de referencia, la unbox.anyinstrucción tiene el mismo efecto que castclasstypeTok.

(ECMA 335 Partición III, 4.32): unbox

Por lo general, unboxsimplemente calcula la dirección del tipo de valor que ya está presente dentro del objeto encuadrado. Este enfoque no es posible al desempaquetar tipos de valores anulables. Debido a que los Nullable<T>valores se convierten en recuadro Tsdurante la operación de recuadro, una implementación a menudo debe fabricar un nuevo Nullable<T>en el montón y calcular la dirección al objeto recién asignado.

Curiosamente, transmití comentarios sobre el soporte del operador al dynamicser un orden de magnitud más lento para Nullable<T>(similar a esta prueba inicial ), sospecho por razones muy similares.

Tengo amor Nullable<T>. Otra divertida es que, aunque el JIT detecta (y elimina) nullestructuras no anulables, lo divide para Nullable<T>:

using System;
using System.Diagnostics;
static class Program {
    static void Main() { 
        // JIT
        TestUnrestricted<int>(1,5);
        TestUnrestricted<string>("abc",5);
        TestUnrestricted<int?>(1,5);
        TestNullable<int>(1, 5);

        const int LOOP = 100000000;
        Console.WriteLine(TestUnrestricted<int>(1, LOOP));
        Console.WriteLine(TestUnrestricted<string>("abc", LOOP));
        Console.WriteLine(TestUnrestricted<int?>(1, LOOP));
        Console.WriteLine(TestNullable<int>(1, LOOP));

    }
    static long TestUnrestricted<T>(T x, int loop) {
        Stopwatch watch = Stopwatch.StartNew();
        int count = 0;
        for (int i = 0; i < loop; i++) {
            if (x != null) count++;
        }
        watch.Stop();
        return watch.ElapsedMilliseconds;
    }
    static long TestNullable<T>(T? x, int loop) where T : struct {
        Stopwatch watch = Stopwatch.StartNew();
        int count = 0;
        for (int i = 0; i < loop; i++) {
            if (x != null) count++;
        }
        watch.Stop();
        return watch.ElapsedMilliseconds;
    }
}

Este es el resultado de FindSumWithAsAndHas arriba:

Este es el resultado de FindSumWithCast:

Recomendaciones:

• Utilizando as, prueba primero si un objeto es una instancia de Int32; debajo del capó que está utilizando isinst Int32(que es similar al código escrito a mano: if (o es int)). Y usando as, también desempaqueta incondicionalmente el objeto. Y es un verdadero asesino de rendimiento llamar a una propiedad (sigue siendo una función oculta), IL_0027

• Usando cast, prueba primero si el objeto es un int if (o is int); debajo del capó que está usando isinst Int32. Si se trata de una instancia de int, puede desempaquetar el valor, IL_002D

En pocas palabras, este es el pseudocódigo del uso del asenfoque:

int? x;

(x.HasValue, x.Value) = (o isinst Int32, o unbox Int32)

if (x.HasValue)
    sum += x.Value;    

Y este es el pseudocódigo del uso del enfoque de conversión:

if (o isinst Int32)
    sum += (o unbox Int32)

Entonces, el (int)a[i]enfoque de conversión ( bueno, la sintaxis se ve como una conversión, pero en realidad es unboxing, cast y unboxing comparten la misma sintaxis, la próxima vez seré pedante con la terminología correcta) el enfoque es realmente más rápido, solo necesitas desempaquetar un valor cuando un objeto es decididamente un int. No se puede decir lo mismo al usar un asenfoque.

Para mantener esta respuesta actualizada, vale la pena mencionar que la mayor parte de la discusión en esta página ahora es discutible ahora con C # 7.1 y .NET 4.7, que admite una sintaxis delgada que también produce el mejor código IL.

El ejemplo original del OP ...

object o = ...;
int? x = o as int?;
if (x.HasValue)
{
    // ...use x.Value in here
}

se convierte simplemente ...

if (o is int x)
{
    // ...use x in here
}

He descubierto que un uso común para la nueva sintaxis es cuando está escribiendo un tipo de valor .NET (es decir, structen C # ) que implementa IEquatable<MyStruct>(como la mayoría debería). Después de implementar el Equals(MyStruct other)método fuertemente tipado , ahora puede redirigir con gracia la Equals(Object obj)anulación sin tipo (heredada de Object) de la siguiente manera:

public override bool Equals(Object obj) => obj is MyStruct o && Equals(o);

Apéndice: La Releaseacumulación de IL código para las dos primeras funciones ejemplo mostrado arriba en esta respuesta (respectivamente) se dan aquí. Si bien el código IL para la nueva sintaxis es de hecho 1 byte más pequeño, en su mayoría gana en grande al hacer cero llamadas (frente a dos) y evitar la unboxoperación por completo cuando sea posible.

// static void test1(Object o, ref int y)
// {
//     int? x = o as int?;
//     if (x.HasValue)
//         y = x.Value;
// }

[0] valuetype [mscorlib]Nullable`1<int32> x
        ldarg.0
        isinst [mscorlib]Nullable`1<int32>
        unbox.any [mscorlib]Nullable`1<int32>
        stloc.0
        ldloca.s x
        call instance bool [mscorlib]Nullable`1<int32>::get_HasValue()
        brfalse.s L_001e
        ldarg.1
        ldloca.s x
        call instance !0 [mscorlib]Nullable`1<int32>::get_Value()
        stind.i4
L_001e: ret

// static void test2(Object o, ref int y)
// {
//     if (o is int x)
//         y = x;
// }

[0] int32 x,
[1] object obj2
        ldarg.0
        stloc.1
        ldloc.1
        isinst int32
        ldnull
        cgt.un
        dup
        brtrue.s L_0011
        ldc.i4.0
        br.s L_0017
L_0011: ldloc.1
        unbox.any int32
L_0017: stloc.0
        brfalse.s L_001d
        ldarg.1
        ldloc.0
        stind.i4
L_001d: ret

Para más pruebas que corroboren mi observación sobre el rendimiento de la nueva sintaxis C # 7 que supera las opciones disponibles anteriormente, consulte aquí (en particular, el ejemplo 'D').

Perfilado adicional:

using System;
using System.Diagnostics;

class Program
{
    const int Size = 30000000;

    static void Main(string[] args)
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i + 1] = "";
            values[i + 2] = 1;
        }

        FindSumWithIsThenCast(values);

        FindSumWithAsThenHasThenValue(values);
        FindSumWithAsThenHasThenCast(values);

        FindSumWithManualAs(values);
        FindSumWithAsThenManualHasThenValue(values);



        Console.ReadLine();
    }

    static void FindSumWithIsThenCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            if (o is int)
            {
                int x = (int)o;
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Is then Cast: {0} : {1}", sum,
                            (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithAsThenHasThenValue(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;

            if (x.HasValue)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As then Has then Value: {0} : {1}", sum,
                            (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithAsThenHasThenCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;

            if (x.HasValue)
            {
                sum += (int)o;
            }
        }
        sw.Stop();
        Console.WriteLine("As then Has then Cast: {0} : {1}", sum,
                            (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithManualAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            bool hasValue = o is int;
            int x = hasValue ? (int)o : 0;

            if (hasValue)
            {
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Manual As: {0} : {1}", sum,
                            (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithAsThenManualHasThenValue(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;

            if (o is int)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As then Manual Has then Value: {0} : {1}", sum,
                            (long)sw.ElapsedMilliseconds);
    }

}

Salida:

Is then Cast: 10000000 : 303
As then Has then Value: 10000000 : 3524
As then Has then Cast: 10000000 : 3272
Manual As: 10000000 : 395
As then Manual Has then Value: 10000000 : 3282

¿Qué podemos inferir de estas cifras?

• En primer lugar, es entonces fundido enfoque es mucho más rápido que lo enfoque. 303 vs 3524
• Segundo, .Value es marginalmente más lento que el casting. 3524 vs 3272
• Tercero, .HasValue es marginalmente más lento que usar has manual (es decir, usar is ). 3524 vs 3282
• En cuarto lugar, haciendo una comparación de manzana a manzana (es decir, tanto la asignación de HasValue simulado y la conversión simulada Valor sucede juntos) entre simulado como y real como enfoque, podemos ver simulado como sigue siendo significativamente más rápido que el real . 395 vs 3524
• Por último, basada en la primera y cuarta conclusión, hay algo de malo en que la aplicación ^ _ ^

No tengo tiempo para probarlo, pero es posible que desee tener:

foreach (object o in values)
        {
            int? x = o as int?;

como

int? x;
foreach (object o in values)
        {
            x = o as int?;

Está creando un nuevo objeto cada vez, que no explicará completamente el problema, pero puede contribuir.

Probé la construcción de verificación de tipo exacto

typeof(int) == item.GetType(), que funciona tan rápido como la item is intversión y siempre devuelve el número (énfasis: incluso si escribió un Nullable<int>a en la matriz, necesitaría usarlo typeof(int)). También necesita un null != itemcheque adicional aquí.

sin embargo

typeof(int?) == item.GetType()permanece rápido (en contraste con item is int?), pero siempre devuelve falso.

El typeof-construct es, en mi opinión, la forma más rápida para la verificación exacta de tipos, ya que utiliza el RuntimeTypeHandle. Dado que los tipos exactos en este caso no coinciden con anulables, supongo que es necesario is/ashacer levantamiento de pesas adicional aquí para garantizar que de hecho sea una instancia de un tipo anulable.

Y honestamente: ¿qué te is Nullable<xxx> plus HasValuecompra? Nada. Siempre puede ir directamente al tipo subyacente (valor) (en este caso). Obtiene el valor o "no, no es una instancia del tipo que estaba solicitando". Incluso si escribió (int?)nullen la matriz, la verificación de tipo devolverá falso.

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i + 1] = "";
            values[i + 2] = 1;
        }

        FindSumWithCast(values);
        FindSumWithAsAndHas(values);
        FindSumWithAsAndIs(values);


        FindSumWithIsThenAs(values);
        FindSumWithIsThenConvert(values);

        FindSumWithLinq(values);



        Console.ReadLine();
    }

    static void FindSumWithCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            if (o is int)
            {
                int x = (int)o;
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Cast: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithAsAndHas(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;
            if (x.HasValue)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As and Has: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }


    static void FindSumWithAsAndIs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {
            int? x = o as int?;
            if (o is int)
            {
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("As and Is: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }







    static void FindSumWithIsThenAs(object[] values)
    {
        // Apple-to-apple comparison with Cast routine above.
        // Using the similar steps in Cast routine above,
        // the AS here cannot be slower than Linq.



        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {

            if (o is int)
            {
                int? x = o as int?;
                sum += x.Value;
            }
        }
        sw.Stop();
        Console.WriteLine("Is then As: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindSumWithIsThenConvert(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = 0;
        foreach (object o in values)
        {            
            if (o is int)
            {
                int x = Convert.ToInt32(o);
                sum += x;
            }
        }
        sw.Stop();
        Console.WriteLine("Is then Convert: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }



    static void FindSumWithLinq(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int sum = values.OfType<int>().Sum();
        sw.Stop();
        Console.WriteLine("LINQ: {0} : {1}", sum,
                          (long)sw.ElapsedMilliseconds);
    }
}

Salidas:

Cast: 10000000 : 456
As and Has: 10000000 : 2103
As and Is: 10000000 : 2029
Is then As: 10000000 : 1376
Is then Convert: 10000000 : 566
LINQ: 10000000 : 1811

[EDITAR: 2010-06-19]

Nota: La prueba anterior se realizó dentro de VS, depuración de configuración, usando VS2009, usando Core i7 (máquina de desarrollo de la compañía).

Lo siguiente se hizo en mi máquina usando Core 2 Duo, usando VS2010

Inside VS, Configuration: Debug

Cast: 10000000 : 309
As and Has: 10000000 : 3322
As and Is: 10000000 : 3249
Is then As: 10000000 : 1926
Is then Convert: 10000000 : 410
LINQ: 10000000 : 2018




Outside VS, Configuration: Debug

Cast: 10000000 : 303
As and Has: 10000000 : 3314
As and Is: 10000000 : 3230
Is then As: 10000000 : 1942
Is then Convert: 10000000 : 418
LINQ: 10000000 : 1944




Inside VS, Configuration: Release

Cast: 10000000 : 305
As and Has: 10000000 : 3327
As and Is: 10000000 : 3265
Is then As: 10000000 : 1942
Is then Convert: 10000000 : 414
LINQ: 10000000 : 1932




Outside VS, Configuration: Release

Cast: 10000000 : 301
As and Has: 10000000 : 3274
As and Is: 10000000 : 3240
Is then As: 10000000 : 1904
Is then Convert: 10000000 : 414
LINQ: 10000000 : 1936