Leistungsüberraschung mit "as" - und nullbaren Typen

Ich überarbeite gerade Kapitel 4 von C # in Depth, das sich mit nullbaren Typen befasst, und füge einen Abschnitt über die Verwendung des Operators "as" hinzu, in dem Sie schreiben können:

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

Ich fand das wirklich ordentlich und konnte die Leistung gegenüber dem C # 1-Äquivalent verbessern, indem "is" gefolgt von einer Besetzung verwendet wurde. Schließlich müssen wir auf diese Weise nur einmal nach einer dynamischen Typprüfung und dann nach einer einfachen Wertprüfung fragen .

Dies scheint jedoch nicht der Fall zu sein. Ich habe unten eine Beispiel-Test-App eingefügt, die im Grunde alle Ganzzahlen in einem Objektarray summiert - aber das Array enthält viele Nullreferenzen und Zeichenfolgenreferenzen sowie Ganzzahlen in Kästchen. Der Benchmark misst den Code, den Sie in C # 1 verwenden müssten, den Code mit dem Operator "as" und nur für Kicks eine LINQ-Lösung. Zu meinem Erstaunen ist der C # 1-Code in diesem Fall 20-mal schneller - und sogar der LINQ-Code (von dem ich angesichts der beteiligten Iteratoren erwartet hätte, dass er langsamer ist) schlägt den "as" -Code.

Ist die .NET-Implementierung isinstfür nullfähige Typen nur sehr langsam? Ist es das zusätzliche unbox.any, das das Problem verursacht? Gibt es eine andere Erklärung dafür? Im Moment scheint es, als müsste ich eine Warnung davor einfügen, dies in leistungsempfindlichen Situationen zu verwenden ...

Ergebnisse:

Besetzung: 10000000: 121
As: 10000000: 2211
LINQ: 10000000: 2143

Code:

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

Der Maschinencode, den der JIT-Compiler für den ersten Fall generieren kann, ist eindeutig viel effizienter. Eine Regel, die dort wirklich hilft, ist, dass ein Objekt nur für eine Variable entpackt werden kann, die denselben Typ wie der umrahmte Wert hat. Dadurch kann der JIT-Compiler sehr effizienten Code generieren, es müssen keine Wertekonvertierungen berücksichtigt werden.

Der is- Operator-Test ist einfach. Überprüfen Sie einfach, ob das Objekt nicht null ist und vom erwarteten Typ ist. Es werden nur einige Anweisungen für den Maschinencode benötigt. Die Umwandlung ist auch einfach, der JIT-Compiler kennt die Position der Wertbits im Objekt und verwendet sie direkt. Es findet kein Kopieren oder Konvertieren statt, der gesamte Maschinencode ist inline und benötigt nur etwa ein Dutzend Anweisungen. Dies musste in .NET 1.0 wirklich effizient sein, als das Boxen üblich war.

Casting nach int? braucht viel mehr Arbeit. Die Wertdarstellung der Boxed Integer ist nicht mit dem Speicherlayout von kompatibel Nullable<int>. Eine Konvertierung ist erforderlich und der Code ist aufgrund möglicher Aufzählungstypen schwierig. Der JIT-Compiler generiert einen Aufruf einer CLR-Hilfsfunktion mit dem Namen JIT_Unbox_Nullable, um die Aufgabe zu erledigen. Dies ist eine Allzweckfunktion für jeden Werttyp, viel Code zum Überprüfen von Typen. Und der Wert wird kopiert. Die Kosten sind schwer abzuschätzen, da dieser Code in mscorwks.dll gesperrt ist, aber wahrscheinlich Hunderte von Maschinencode-Anweisungen.

Die Erweiterungsmethode Linq OfType () verwendet auch den Operator is und die Umwandlung . Dies ist jedoch eine Umwandlung in einen generischen Typ. Der JIT-Compiler generiert einen Aufruf einer Hilfsfunktion, JIT_Unbox (), die eine Umwandlung in einen beliebigen Werttyp durchführen kann. Ich habe keine gute Erklärung dafür, warum es so langsam ist wie die Besetzung Nullable<int>, da weniger Arbeit notwendig sein sollte. Ich vermute, dass ngen.exe hier Probleme verursachen könnte.

Es scheint mir, dass das isinstbei nullbaren Typen nur sehr langsam ist. In der Methode habe FindSumWithCastich mich geändert

if (o is int)

zu

if (o is int?)

Dies verlangsamt auch die Ausführung erheblich. Der einzige Unterschied in IL, den ich sehen kann, ist der

isinst     [mscorlib]System.Int32

wird geändert zu

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

Dies begann ursprünglich als Kommentar zu Hans Passants ausgezeichneter Antwort, aber es wurde zu lang, deshalb möchte ich hier ein paar Kleinigkeiten hinzufügen:

Zuerst gibt der C # as-Operator einen isinstIL-Befehl aus (der isOperator auch). (Eine weitere interessante Anweisung wird castclassausgegeben, wenn Sie eine direkte Umwandlung durchführen und der Compiler weiß, dass die Laufzeitprüfung nicht ausgelassen werden kann.)

Folgendes isinstfunktioniert ( ECMA 335 Partition III, 4.6 ):

Format: isinst typeTok

typeTok ist ein Metadatentoken (a typeref, typedefoder typespec), die gewünschte Klasse angibt.

Wenn typeTok ein nicht nullbarer Werttyp oder ein generischer Parametertyp ist, wird er als "boxed" typeTok interpretiert .

Wenn typeTok ein nullfähiger Typ ist Nullable<T>, wird er als "boxed" interpretiert.T

Am wichtigsten:

Wenn die Ist - Typ (nicht der Verifizierer verfolgt Typ) von obj ist Verifizierer zuweisbare zu dem Typ typeTok dann isinsterfolgreich ist und obj (als Ergebnis ) zurückgegeben unverändert , während Überprüfung seiner Art als Spuren typeTok . Im Gegensatz zu Zwängen (§1.6) und Konvertierungen (§3.27) isinständert sich niemals der tatsächliche Typ eines Objekts und die Objektidentität bleibt erhalten (siehe Partition I).

Der Performance-Killer ist also nicht isinstin diesem Fall, sondern der zusätzliche unbox.any. Dies ging aus Hans 'Antwort nicht hervor, da er nur den JITed-Code betrachtete. Im Allgemeinen gibt der C # -Compiler ein unbox.anyNach-a aus isinst T?(lässt es jedoch weg isinst T, wenn Sie dies tun , wenn Tes sich um einen Referenztyp handelt).

Warum macht es das? isinst T?hat nie den Effekt, der offensichtlich gewesen wäre, dh Sie erhalten a zurück T?. Stattdessen stellen alle diese Anweisungen sicher, dass Sie eine haben "boxed T", für die eine Box ausgepackt werden kann T?. Um ein aktuelles zu erhalten T?, müssen wir unser "boxed T"to noch entpacken T?, weshalb der Compiler ein unbox.anyAfter ausgibt isinst. Wenn Sie darüber nachdenken, ist dies sinnvoll, da das "Box-Format" T?nur ein "boxed T"ist castclassund isinstdas Erstellen und Ausführen der Unbox inkonsistent wäre.

Das Ergebnis von Hans mit einigen Informationen aus dem Standard untermauern , hier ist es:

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

Bei Anwendung auf die unbox.anyBoxform eines Werttyps extrahiert die Anweisung den in obj (vom Typ O) enthaltenen Wert . ( Dies entspricht " unboxgefolgt von" ldobj.) Bei Anwendung auf einen Referenztyp hat die unbox.anyAnweisung den gleichen Effekt wie castclasstypeTok.

(ECMA 335 Partition III, 4.32): unbox

unboxBerechnet in der Regel einfach die Adresse des Werttyps, der bereits im umrahmten Objekt vorhanden ist. Dieser Ansatz ist nicht möglich, wenn nullfähige Werttypen entpackt werden. Da Nullable<T>Werte Tswährend der Boxoperation in Box konvertiert werden, muss eine Implementierung häufig eine neue Nullable<T>auf dem Heap erstellen und die Adresse für das neu zugewiesene Objekt berechnen.

Interessanterweise gab ich Feedback zur Bedienerunterstützung weiter, dynamicindem ich um eine Größenordnung langsamer war Nullable<T>(ähnlich wie bei diesem frühen Test ) - ich vermute aus sehr ähnlichen Gründen.

Muss ich lieben Nullable<T>. Ein weiterer Spaß ist, dass die JIT zwar nullnicht nullfähige Strukturen erkennt (und entfernt) , sie jedoch für Folgendes borkt 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;
    }
}

Dies ist das Ergebnis von FindSumWithAsAndHas oben:

Dies ist das Ergebnis von FindSumWithCast:

Ergebnisse:

• Mit aswird zunächst geprüft, ob ein Objekt eine Instanz von Int32 ist. unter der Haube wird es verwendet isinst Int32(ähnlich wie handgeschriebener Code: if (o is int)). Mit aswird das Objekt auch bedingungslos entpackt. Und es ist ein echter Leistungskiller, eine Eigenschaft (es ist immer noch eine Funktion unter der Haube) IL_0027 zu nennen

• Mit cast testen Sie zuerst, ob das Objekt ein ist int if (o is int). unter der Haube wird dies verwendet isinst Int32. Wenn es sich um eine Instanz von int handelt, können Sie den Wert IL_002D sicher entpacken

Einfach ausgedrückt ist dies der Pseudocode für die Verwendung des asAnsatzes:

int? x;

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

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

Und dies ist der Pseudocode für die Verwendung des Cast-Ansatzes:

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

Der Cast- (int)a[i]Ansatz (nun , die Syntax sieht aus wie ein Cast, aber es ist tatsächlich Unboxing, Cast und Unboxing haben dieselbe Syntax, das nächste Mal, wenn ich mit der richtigen Terminologie pedantisch bin) ist wirklich schneller, Sie müssen nur einen Wert entpacken wenn ein Objekt entschieden ein ist int. Das Gleiche gilt nicht für einen asAnsatz.

Um diese Antwort auf dem neuesten Stand zu halten, ist es erwähnenswert, dass der größte Teil der Diskussion auf dieser Seite jetzt mit C # 7.1 und .NET 4.7 diskutiert wird , die eine schlanke Syntax unterstützen, die auch den besten IL-Code erzeugt.

Das ursprüngliche Beispiel des OP ...

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

wird einfach ...

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

Ich habe festgestellt, dass eine häufige Verwendung für die neue Syntax darin besteht, einen .NET- Werttyp (dh structin C # ) zu schreiben , der implementiert wird IEquatable<MyStruct>(wie die meisten sollten). Nach der Implementierung der stark typisierten Equals(MyStruct other)Methode können Sie die nicht typisierte Equals(Object obj)Überschreibung (von der geerbt wurde Object) wie folgt ordnungsgemäß umleiten :

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

Anhang: Der ReleaseBuild- IL- Code für die ersten beiden oben in dieser Antwort gezeigten Beispielfunktionen ist hier angegeben. Während der IL-Code für die neue Syntax tatsächlich 1 Byte kleiner ist, gewinnt er meistens groß, indem er keine Aufrufe (gegenüber zwei) tätigt und die unboxOperation nach Möglichkeit ganz vermeidet .

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

Weitere Tests, die meine Bemerkung zur Leistung der neuen C # 7- Syntax untermauern, die die zuvor verfügbaren Optionen übertrifft, finden Sie hier (insbesondere Beispiel 'D').

Profilierung weiter:

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

}

Ausgabe:

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

Was können wir aus diesen Zahlen schließen?

• Erstens ist der Is-Then-Cast-Ansatz erheblich schneller als der Ansatz. 303 gegen 3524
• Zweitens ist der Wert geringfügig langsamer als das Gießen. 3524 gegen 3272
• Drittens ist .HasValue geringfügig langsamer als die manuelle Verwendung (dh die Verwendung von is ). 3524 gegen 3282
• Viertens: Wenn wir einen Apfel-zu-Apfel-Vergleich durchführen (dh sowohl das Zuweisen von simuliertem HasValue als auch das Konvertieren von simuliertem Wert erfolgt gemeinsam) zwischen simuliertem und realem Ansatz, können wir sehen, dass simuliert als immer noch erheblich schneller als real als ist . 395 vs 3524
• Schließlich, basierend auf der ersten und vierten Schlussfolgerung, stimmt etwas nicht mit der Implementierung ^ _ ^

Ich habe keine Zeit, es zu versuchen, aber vielleicht möchten Sie:

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

wie

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

Sie erstellen jedes Mal ein neues Objekt, das das Problem nicht vollständig erklärt, aber möglicherweise dazu beiträgt.

Ich habe das genaue Konstrukt der Typprüfung ausprobiert

typeof(int) == item.GetType()Dies ist genauso schnell wie die item is intVersion und gibt immer die Nummer zurück (Hervorhebung: Selbst wenn Sie eine Nullable<int>in das Array geschrieben haben, müssten Sie diese verwenden typeof(int)). Sie benötigen null != itemhier auch einen zusätzlichen Scheck.

jedoch

typeof(int?) == item.GetType()bleibt schnell (im Gegensatz zu item is int?), gibt aber immer false zurück.

Das Typeof-Konstrukt ist in meinen Augen der schnellste Weg zur genauen Typprüfung, da es das RuntimeTypeHandle verwendet. Da die genauen Typen in diesem Fall nicht mit nullable übereinstimmen, muss ich meiner is/asMeinung nach hier zusätzliches Heavy-Lifting durchführen, um sicherzustellen, dass es sich tatsächlich um eine Instanz eines nullable-Typs handelt.

Und ehrlich: Was is Nullable<xxx> plus HasValuekaufst du dir? Nichts. Sie können jederzeit direkt zum zugrunde liegenden (Wert-) Typ wechseln (in diesem Fall). Sie erhalten entweder den Wert oder "Nein, keine Instanz des Typs, nach dem Sie gefragt haben". Selbst wenn Sie (int?)nullin das Array geschrieben haben, gibt die Typprüfung false zurück.

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

Ausgänge:

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]

Hinweis: Der vorherige Test wurde in VS, Konfigurationsdebug, unter Verwendung von VS2009 unter Verwendung von Core i7 (Unternehmensentwicklungsmaschine) durchgeführt.

Das Folgende wurde auf meinem Computer mit Core 2 Duo unter Verwendung von VS2010 durchgeführt

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