Niespodzianka wydajnościowa z typami „as” i zerowalnymi

Właśnie przeglądam rozdział 4 C # w Depth, który dotyczy typów zerowalnych, i dodaję sekcję o używaniu operatora „as”, który pozwala pisać:

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

Myślałem, że to naprawdę fajne i że może poprawić wydajność w stosunku do C # 1, używając „jest”, a następnie rzutowania - w końcu w ten sposób musimy poprosić tylko o dynamiczne sprawdzenie typu, a następnie proste sprawdzenie wartości .

Jednak wydaje się, że tak nie jest. Poniżej zamieściłem przykładową aplikację testową, która w zasadzie sumuje wszystkie liczby całkowite w tablicy obiektów - ale tablica zawiera wiele odwołań zerowych i odniesień łańcuchowych, a także liczb całkowitych w ramkach. Benchmark mierzy kod, którego należy użyć w języku C # 1, kod za pomocą operatora „as” i tylko dla rozwiązania LINQ. Ku mojemu zdziwieniu kod C # 1 jest w tym przypadku 20 razy szybszy - a nawet kod LINQ (który, jak się spodziewałam, byłby wolniejszy, biorąc pod uwagę zaangażowane iteratory) bije kod „jak”.

Czy implementacja .NET isinstdla typów zerowalnych jest po prostu bardzo wolna? Czy to dodatkoweunbox.any problem powoduje problem? Czy jest na to inne wytłumaczenie? W tej chwili wydaje mi się, że będę musiał dołączyć ostrzeżenie przed użyciem tego w sytuacjach wrażliwych na wydajność ...

Wyniki:

Obsada: 10000000: 121
Jako: 10000000: 2211
LINQ: 10000000: 2143

Kod:

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

Oczywiście kod maszynowy, który kompilator JIT może wygenerować dla pierwszego przypadku, jest znacznie bardziej wydajny. Jedną z zasad, która naprawdę tam pomaga, jest to, że obiekt można rozpakować tylko do zmiennej, która ma ten sam typ, co wartość pudełkowa. Dzięki temu kompilator JIT może generować bardzo wydajny kod, nie trzeba brać pod uwagę konwersji wartości.

jest badanie operator jest proste, wystarczy sprawdzić, czy obiekt nie jest nieważna i jest oczekiwanego typu, ale trwa kilka instrukcje kodu maszynowego. Rzutowanie jest również łatwe, kompilator JIT zna położenie bitów wartości w obiekcie i używa ich bezpośrednio. Kopiowanie lub konwersja nie występuje, cały kod maszynowy jest wbudowany i zajmuje około tuzina instrukcji. To musiało być naprawdę wydajne w .NET 1.0, gdy boks był powszechny.

Przesyłam na int? zajmuje dużo więcej pracy. Reprezentacja wartości pudełkowatej liczby całkowitej jest niezgodna z układem pamięci Nullable<int>. Wymagana jest konwersja, a kod jest trudny ze względu na możliwe typy wyliczeń w pudełku. Kompilator JIT generuje wywołanie funkcji pomocniczej CLR o nazwie JIT_Unbox_Nullable, aby wykonać zadanie. Jest to funkcja ogólnego przeznaczenia dla dowolnego typu wartości, z dużą ilością kodu do sprawdzania typów. Wartość jest kopiowana. Trudno oszacować koszt, ponieważ ten kod jest zamknięty w pliku mscorwks.dll, ale prawdopodobnie setki instrukcji kodu maszynowego.

Metoda rozszerzenia Linq OfType () również używa operatora is i rzutowania. Jest to jednak obsada typu ogólnego. Kompilator JIT generuje wywołanie funkcji pomocniczej JIT_Unbox (), która może wykonać rzutowanie na dowolny typ wartości. Nie mam wielkiego wyjaśnienia, dlaczego jest tak powolny jak obsada Nullable<int>, biorąc pod uwagę, że mniej pracy powinno być konieczne. Podejrzewam, że ngen.exe może powodować problemy tutaj.

Wydaje mi się, że w przypadku isinsttypów zerowalnych jest to bardzo powolne. W metodzie FindSumWithCastzmieniłem

if (o is int)

do

if (o is int?)

co również znacznie spowalnia wykonanie. Jedyne różnice w IL, jakie widzę, to to

isinst     [mscorlib]System.Int32

zmienia się na

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

Zaczęło się to od komentarza do doskonałej odpowiedzi Hansa Passanta, ale trwało zbyt długo, więc chcę tutaj dodać kilka bitów:

Po pierwsze, asoperator C # wyśle isinstinstrukcję IL (podobnie jak isoperator). (Kolejna interesująca instrukcja jest castclassemitowana podczas bezpośredniego przesyłania, a kompilator wie, że nie można pominąć sprawdzania czasu wykonywania).

Oto, co isinstrobi ( ECMA 335 Partition III, 4.6 ):

Format: isinst typeTok

typeTok jest wyrazem metadanych (a typeref, typedefi typespec), co wskazuje pożądaną klasę.

Jeśli typeTok jest niedozwolonym typem wartości lub ogólnym typem parametru, jest interpretowany jako „boxed” typeTok .

Jeśli typeTok jest typem zerowalnym Nullable<T>, jest interpretowany jako „pudełkowany”T

Najważniejsze:

Jeśli rzeczywisty typ obiektu (nie typ śledzenia przez weryfikatora) obj jest weryfikatorem-przypisywalnym- typowi typeTok, to się isinstpowiedzie i obiekt obj (jako wynik ) zostanie zwrócony bez zmian, podczas gdy weryfikacja śledzi jego typ jako typeTok . W przeciwieństwie do koercji (§ 1.6) i konwersji (§3.27), isinstnigdy nie zmienia faktycznego typu obiektu i zachowuje tożsamość obiektu (patrz Partycja I).

Tak więc zabójca wydajności nie jest isinstw tym przypadku, ale dodatkowym unbox.any. Nie było to jasne w odpowiedzi Hansa, gdy spojrzał tylko na kod JITed. Ogólnie rzecz biorąc, kompilator C # będzie emitował unbox.anypo nim isinst T?(ale pominie go w przypadku isinst T, gdy Tto zrobisz , kiedy jest typem odniesienia).

Dlaczego to robi? isinst T?nigdy nie ma efektu, który byłby oczywisty, tzn. odzyskasz T?. Zamiast tego, wszystkie te instrukcje zapewniają, że masz do "boxed T"rozpakowania T?. Aby uzyskać rzeczywisty T?, nadal musimy rozpakować nasze "boxed T"do T?, i dlatego kompilator emituje unbox.anypo isinst. Jeśli się nad tym zastanowić, ma to sens, ponieważ „format skrzynki” T?to po prostu "boxed T"a tworzenie castclassi isinstwykonywanie rozpakowywania byłoby niespójne.

Kopię zapasową odkrycia Hansa z pewnymi informacjami ze standardu , oto:

(ECMA 335 Partition III, 4.33): unbox.any

Po zastosowaniu do postaci pudełkowej typu wartości unbox.anyinstrukcja wyodrębnia wartość zawartą w obiekcie obj (typu O). (Odpowiada to, unboxpo której następuje ldobj). Po zastosowaniu do typu referencyjnego unbox.anyinstrukcja ma taki sam efekt jak castclasstypeTok.

(ECMA 335 partycja III, 4.32): unbox

Zwykle unboxpo prostu oblicza adres typu wartości, który jest już obecny wewnątrz obiektu w ramce. To podejście nie jest możliwe, gdy rozpakowujesz typy wartości dopuszczających wartości zerowe. Ponieważ Nullable<T>wartości są konwertowane Tsna ramkę podczas operacji skrzynki, implementacja często musi wytworzyć nową Nullable<T>na stercie i obliczyć adres do nowo przydzielonego obiektu.

Co ciekawe, przekazałem informację zwrotną na temat wsparcia operatora, dynamicponieważ byłem wolniejszy o rząd wielkości Nullable<T>(podobnie jak w tym wczesnym teście ) - podejrzewam z bardzo podobnych powodów.

Musisz kochać Nullable<T>. Kolejną zabawną rzeczą jest to, że chociaż JIT nullrozpoznaje (i usuwa) struktury niedozwolone, to rozdziela go na 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;
    }
}

Jest to wynik FindSumWithAsAndHas powyżej:

Jest to wynik FindSumWithCast:

Wyniki:

• Używając as, najpierw sprawdza, czy obiekt jest instancją Int32; pod maską używa isinst Int32(który jest podobny do odręcznego kodu: if (o jest int)). I przy użyciu asbezwarunkowo rozpakowuje również obiekt. I jest prawdziwym zabójcą wydajności nazywanie właściwości (wciąż jest to funkcja pod maską), IL_0027

• Za pomocą rzutowania najpierw testujesz, czy obiekt jest int if (o is int); używa tego pod maską isinst Int32. Jeśli jest to instancja int, możesz bezpiecznie rozpakować wartość IL_002D

Mówiąc najprościej, jest to pseudo-kod użycia asmetody:

int? x;

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

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

A to pseudo-kod użycia metody rzutowania:

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

Więc rzutowanie ( (int)a[i]no cóż, składnia wygląda jak rzutowanie, ale tak naprawdę rozpakowywanie, rzutowanie i rozpakowywanie mają tę samą składnię, następnym razem będę pedantyczny z właściwą terminologią) podejście jest naprawdę szybsze, wystarczy tylko rozpakować wartość gdy obiekt jest zdecydowanie int. Tego samego nie można powiedzieć o zastosowaniu aspodejścia.

Aby zachować aktualność tej odpowiedzi, warto wspomnieć, że większość dyskusji na tej stronie jest teraz dyskusyjna dzięki C # 7.1 i .NET 4.7, które obsługują wąską składnię, która również wytwarza najlepszy kod IL.

Oryginalny przykład PO ...

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

staje się po prostu ...

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

Odkryłem, że jednym z powszechnych zastosowań nowej składni jest pisanie typu wartości .NET (tj. structW języku C # ), który implementuje IEquatable<MyStruct>(jak większość powinna). Po zaimplementowaniu metody o silnym typie Equals(MyStruct other)możesz teraz z wdziękiem przekierować do niej niepopisane Equals(Object obj)zastąpienie (dziedziczone z Object) w następujący sposób:

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

Dodatek: Tutaj podano kod Releasekompilacji IL dla pierwszych dwóch przykładowych funkcji pokazanych powyżej w tej odpowiedzi (odpowiednio). Chociaż kod IL dla nowej składni jest rzeczywiście o 1 bajt mniejszy, to najczęściej wygrywa duży, wykonując zero wywołań (w porównaniu do dwóch) i unikając unboxoperacji, jeśli to możliwe.

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

Dalsze testy, które potwierdzają moją uwagę na temat wydajności nowej składni C # 7 przewyższającej wcześniej dostępne opcje, zobacz tutaj (w szczególności przykład „D”).

Dalsze profilowanie:

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

}

Wynik:

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

Co możemy wywnioskować z tych liczb?

• Po pierwsze, jest-then-cast podejście jest znacznie szybszy niż w podejściu. 303 vs 3524
• Po drugie, .Value jest nieznacznie wolniejszy niż casting. 3524 vs 3272
• Po trzecie, .HasValue jest nieznacznie wolniejszy niż używanie manualne (tzn. Używanie is ). 3524 vs 3282
• Po czwarte, robi jabłko-do-jabłek porównanie (czyli zarówno przypisanie symulowanych hasValue i konwersja symulowanych Wartość dzieje razem) pomiędzy symulowane jak i prawdziwe jak podejścia, widzimy symulowane jak jest nadal znacznie szybciej niż prawdziwe jak . 395 vs 3524
• Wreszcie, na podstawie pierwszego i czwartego wniosku, że jest coś złego w realizacji ^ _ ^

Nie mam czasu, aby spróbować, ale możesz chcieć mieć:

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

tak jak

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

Za każdym razem tworzysz nowy obiekt, który nie do końca wyjaśni problem, ale może się przydać.

Wypróbowałem dokładną konstrukcję sprawdzania typu

typeof(int) == item.GetType(), który działa tak szybko, jak item is intwersja i zawsze zwraca liczbę (podkreślenie: nawet jeśli napisałeś Nullable<int>tablicę, musisz użyć typeof(int)). Potrzebujesz także dodatkowego null != itemczeku tutaj.

jednak

typeof(int?) == item.GetType()pozostaje szybki (w przeciwieństwie do item is int?), ale zawsze zwraca false.

Typeof-construct jest moim zdaniem najszybszym sposobem na dokładne sprawdzenie typu, ponieważ wykorzystuje on RuntimeTypeHandle. Ponieważ dokładne typy w tym przypadku nie pasują do wartości zerowej, sądzę, is/asże muszę tutaj wykonać dodatkowe podnoszenie ciężarów, upewniając się, że jest to rzeczywiście przypadek typu zerowalnego.

I szczerze mówiąc: co is Nullable<xxx> plus HasValuekupujesz? Nic. Zawsze możesz przejść bezpośrednio do bazowego (wartości) typu (w tym przypadku). Dostajesz wartość lub „nie, nie instancję typu, o który prosiłeś”. Nawet jeśli napisałeś (int?)nulldo tablicy, sprawdzanie typu zwróci false.

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

Wyjścia:

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

[EDIT: 2010-06-19]

Uwaga: poprzedni test został przeprowadzony wewnątrz VS, debugowania konfiguracji, przy użyciu VS2009, przy użyciu Core i7 (firmowa maszyna programistyczna).

Poniższe czynności zostały wykonane na moim komputerze przy użyciu Core 2 Duo i 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