Beeinträchtigen Try / Catch-Blöcke die Leistung, wenn keine Ausnahmen ausgelöst werden?

Bei einer Codeüberprüfung mit einem Microsoft-Mitarbeiter stießen wir auf einen großen Codeabschnitt innerhalb eines try{}Blocks. Sie und ein IT-Vertreter schlugen vor, dass dies Auswirkungen auf die Leistung des Codes haben könnte. Tatsächlich schlugen sie vor, dass der größte Teil des Codes außerhalb von Try / Catch-Blöcken liegen sollte und dass nur wichtige Abschnitte überprüft werden sollten. Der Microsoft-Mitarbeiter fügte hinzu und sagte, ein bevorstehendes Whitepaper warne vor falschen Try / Catch-Blöcken.

Ich habe mich umgesehen und festgestellt, dass dies Auswirkungen auf Optimierungen haben kann , aber es scheint nur zuzutreffen, wenn eine Variable von mehreren Bereichen gemeinsam genutzt wird.

Ich frage nicht nach der Wartbarkeit des Codes oder nach der Behandlung der richtigen Ausnahmen (der betreffende Code muss zweifellos neu faktorisiert werden). Ich beziehe mich auch nicht auf die Verwendung von Ausnahmen für die Flusskontrolle, dies ist in den meisten Fällen eindeutig falsch. Das sind wichtige Themen (einige sind wichtiger), aber nicht der Fokus hier.

Wie wirken sich Try / Catch-Blöcke auf die Leistung aus, wenn keine Ausnahmen ausgelöst werden?

Prüfen Sie.

static public void Main(string[] args)
{
    Stopwatch w = new Stopwatch();
    double d = 0;

    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        try
        {
            d = Math.Sin(1);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }
    }

    w.Stop();
    Console.WriteLine(w.Elapsed);
    w.Reset();
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        d = Math.Sin(1);
    }

    w.Stop();
    Console.WriteLine(w.Elapsed);
}

Ausgabe:

00:00:00.4269033  // with try/catch
00:00:00.4260383  // without.

In Millisekunden:

449
416

Neuer Code:

for (int j = 0; j < 10; j++)
{
    Stopwatch w = new Stopwatch();
    double d = 0;
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        try
        {
            d = Math.Sin(d);
        }

        catch (Exception ex)
        {
            Console.WriteLine(ex.ToString());
        }

        finally
        {
            d = Math.Sin(d);
        }
    }

    w.Stop();
    Console.Write("   try/catch/finally: ");
    Console.WriteLine(w.ElapsedMilliseconds);
    w.Reset();
    d = 0;
    w.Start();

    for (int i = 0; i < 10000000; i++)
    {
        d = Math.Sin(d);
        d = Math.Sin(d);
    }

    w.Stop();
    Console.Write("No try/catch/finally: ");
    Console.WriteLine(w.ElapsedMilliseconds);
    Console.WriteLine();
}

Neue Ergebnisse:

   try/catch/finally: 382
No try/catch/finally: 332

   try/catch/finally: 375
No try/catch/finally: 332

   try/catch/finally: 376
No try/catch/finally: 333

   try/catch/finally: 375
No try/catch/finally: 330

   try/catch/finally: 373
No try/catch/finally: 329

   try/catch/finally: 373
No try/catch/finally: 330

   try/catch/finally: 373
No try/catch/finally: 352

   try/catch/finally: 374
No try/catch/finally: 331

   try/catch/finally: 380
No try/catch/finally: 329

   try/catch/finally: 374
No try/catch/finally: 334

Nachdem ich alle Statistiken mit try / catch und ohne try / catch gesehen hatte, zwang mich die Neugier, nach hinten zu schauen, um zu sehen, was für beide Fälle generiert wird. Hier ist der Code:

C #:

private static void TestWithoutTryCatch(){
    Console.WriteLine("SIN(1) = {0} - No Try/Catch", Math.Sin(1)); 
}

MSIL:

.method private hidebysig static void  TestWithoutTryCatch() cil managed
{
  // Code size       32 (0x20)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "SIN(1) = {0} - No Try/Catch"
  IL_0006:  ldc.r8     1.
  IL_000f:  call       float64 [mscorlib]System.Math::Sin(float64)
  IL_0014:  box        [mscorlib]System.Double
  IL_0019:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                object)
  IL_001e:  nop
  IL_001f:  ret
} // end of method Program::TestWithoutTryCatch

C #:

private static void TestWithTryCatch(){
    try{
        Console.WriteLine("SIN(1) = {0}", Math.Sin(1)); 
    }
    catch (Exception ex){
        Console.WriteLine(ex);
    }
}

MSIL:

.method private hidebysig static void  TestWithTryCatch() cil managed
{
  // Code size       49 (0x31)
  .maxstack  2
  .locals init ([0] class [mscorlib]System.Exception ex)
  IL_0000:  nop
  .try
  {
    IL_0001:  nop
    IL_0002:  ldstr      "SIN(1) = {0}"
    IL_0007:  ldc.r8     1.
    IL_0010:  call       float64 [mscorlib]System.Math::Sin(float64)
    IL_0015:  box        [mscorlib]System.Double
    IL_001a:  call       void [mscorlib]System.Console::WriteLine(string,
                                                                  object)
    IL_001f:  nop
    IL_0020:  nop
    IL_0021:  leave.s    IL_002f //JUMP IF NO EXCEPTION
  }  // end .try
  catch [mscorlib]System.Exception 
  {
    IL_0023:  stloc.0
    IL_0024:  nop
    IL_0025:  ldloc.0
    IL_0026:  call       void [mscorlib]System.Console::WriteLine(object)
    IL_002b:  nop
    IL_002c:  nop
    IL_002d:  leave.s    IL_002f
  }  // end handler
  IL_002f:  nop
  IL_0030:  ret
} // end of method Program::TestWithTryCatch

Ich bin kein IL-Experte, aber wir können sehen, dass ein lokales Ausnahmeobjekt in der vierten Zeile erstellt wird. .locals init ([0] class [mscorlib]System.Exception ex)Danach sind die Dinge ziemlich die gleichen wie bei Methoden ohne try / catch bis zur Zeile siebzehn IL_0021: leave.s IL_002f. Wenn eine Ausnahme auftritt, springt die Steuerung zur Zeile, IL_0025: ldloc.0andernfalls springen wir zur Bezeichnung IL_002d: leave.s IL_002fund die Funktionsrückgabe.

Ich kann mit Sicherheit davon ausgehen , dass , wenn keine Ausnahmen auftreten , dann ist es der Overhead von lokalen Variablen zu halten Ausnahme Erstellen von Objekten nur und ein Sprungbefehl.

Nein. Wenn die trivialen Optimierungen, die ein try / finally-Block ausschließt, tatsächlich messbare Auswirkungen auf Ihr Programm haben, sollten Sie .NET wahrscheinlich gar nicht erst verwenden.

Ziemlich umfassende Erklärung des .NET-Ausnahmemodells.

Rico Marianis Performance-Leckerbissen: Ausnahmekosten: Wann werfen und wann nicht?

Die erste Art von Kosten sind die statischen Kosten für die Ausnahmebehandlung in Ihrem Code. Verwaltete Ausnahmen sind hier tatsächlich vergleichsweise gut, womit ich meine, dass die statischen Kosten viel niedriger sein können als beispielsweise in C ++. Warum ist das? Nun, statische Kosten entstehen wirklich an zwei Arten von Orten: Erstens an den tatsächlichen Sites von try / finally / catch / throw, an denen Code für diese Konstrukte vorhanden ist. Zweitens entstehen in unverändertem Code die Stealth-Kosten, die mit der Verfolgung aller Objekte verbunden sind, die für den Fall, dass eine Ausnahme ausgelöst wird, zerstört werden müssen. Es muss eine beträchtliche Menge an Bereinigungslogik vorhanden sein, und der hinterhältige Teil ist, dass selbst Code dies nicht tut.

Dmitriy Zaslavskiy:

Laut Chris Brummes Anmerkung: Es gibt auch Kosten im Zusammenhang mit der Tatsache, dass einige Optimierungen von JIT nicht durchgeführt werden, wenn Fang vorhanden ist

Die Struktur unterscheidet sich in dem Beispiel von Ben M . Es wird über Kopf innerhalb der inneren forSchleife erweitert, was dazu führt, dass es keinen guten Vergleich zwischen den beiden Fällen gibt.

Das Folgende ist genauer zum Vergleich, wenn sich der gesamte zu überprüfende Code (einschließlich der Variablendeklaration) im Try / Catch-Block befindet:

        for (int j = 0; j < 10; j++)
        {
            Stopwatch w = new Stopwatch();
            w.Start();
            try { 
                double d1 = 0; 
                for (int i = 0; i < 10000000; i++) { 
                    d1 = Math.Sin(d1);
                    d1 = Math.Sin(d1); 
                } 
            }
            catch (Exception ex) {
                Console.WriteLine(ex.ToString()); 
            }
            finally { 
                //d1 = Math.Sin(d1); 
            }
            w.Stop(); 
            Console.Write("   try/catch/finally: "); 
            Console.WriteLine(w.ElapsedMilliseconds); 
            w.Reset(); 
            w.Start(); 
            double d2 = 0; 
            for (int i = 0; i < 10000000; i++) { 
                d2 = Math.Sin(d2);
                d2 = Math.Sin(d2); 
            } 
            w.Stop(); 
            Console.Write("No try/catch/finally: "); 
            Console.WriteLine(w.ElapsedMilliseconds); 
            Console.WriteLine();
        }

Als ich den ursprünglichen Testcode von Ben M ausführte, bemerkte ich einen Unterschied sowohl in der Debug- als auch in der Releas-Konfiguration.

Bei dieser Version bemerkte ich einen Unterschied in der Debug-Version (tatsächlich mehr als in der anderen Version), aber es war kein Unterschied in der Release-Version.

Conclution :
Basierend auf diesen Test, denke ichwir versuchendass sagen kann / Fang hat einen geringen Einfluss aufLeistung haben.

BEARBEITEN:
Ich habe versucht, den Schleifenwert von 10000000 auf 1000000000 zu erhöhen, und bin in Release erneut ausgeführt worden, um einige Unterschiede in der Version zu erhalten. Das Ergebnis war Folgendes:

   try/catch/finally: 509
No try/catch/finally: 486

   try/catch/finally: 479
No try/catch/finally: 511

   try/catch/finally: 475
No try/catch/finally: 477

   try/catch/finally: 477
No try/catch/finally: 475

   try/catch/finally: 475
No try/catch/finally: 476

   try/catch/finally: 477
No try/catch/finally: 474

   try/catch/finally: 475
No try/catch/finally: 475

   try/catch/finally: 476
No try/catch/finally: 476

   try/catch/finally: 475
No try/catch/finally: 476

   try/catch/finally: 475
No try/catch/finally: 474

Sie sehen, dass das Ergebnis nicht relevant ist. In einigen Fällen ist die Version mit Try / Catch tatsächlich schneller!

Ich habe die tatsächlichen Auswirkungen von a try..catchin einer engen Schleife getestet und es ist zu klein, um in jeder normalen Situation ein Leistungsproblem zu sein.

Wenn die Schleife nur sehr wenig Arbeit leistet (in meinem Test habe ich eine durchgeführt x++), können Sie die Auswirkungen der Ausnahmebehandlung messen. Die Ausführung der Schleife mit Ausnahmebehandlung dauerte etwa zehnmal länger.

Wenn die Schleife tatsächlich arbeitet (in meinem Test habe ich die Int32.Parse-Methode aufgerufen), hat die Ausnahmebehandlung zu wenig Auswirkungen, um messbar zu sein. Ich habe einen viel größeren Unterschied gemacht, indem ich die Reihenfolge der Schleifen vertauscht habe ...

try catch-Blöcke haben einen vernachlässigbaren Einfluss auf die Leistung, aber die Ausnahme Das Werfen kann ziemlich groß sein. Dies ist wahrscheinlich der Punkt, an dem Ihr Mitarbeiter verwirrt war.

Der Versuch / Fang hat Auswirkungen auf die Leistung.

Aber es ist keine große Auswirkung. Die Try / Catch-Komplexität ist im Allgemeinen O (1), genau wie eine einfache Zuweisung, außer wenn sie in einer Schleife platziert sind. Sie müssen sie also mit Bedacht einsetzen.

Hier ist eine Referenz zur Try / Catch-Leistung (erklärt die Komplexität zwar nicht, ist aber impliziert). Werfen Sie einen Blick auf den Abschnitt Weniger Ausnahmen werfen

Theoretisch hat ein Try / Catch-Block keine Auswirkung auf das Codeverhalten, es sei denn, es tritt tatsächlich eine Ausnahme auf. Es gibt jedoch einige seltene Umstände, in denen das Vorhandensein eines Try / Catch-Blocks einen großen Effekt haben kann, und einige ungewöhnliche, aber kaum undurchsichtige, in denen der Effekt spürbar sein kann. Der Grund dafür ist der gegebene Code wie:

Action q;
double thing1()
  { double total; for (int i=0; i<1000000; i++) total+=1.0/i; return total;}
double thing2()
  { q=null; return 1.0;}
...
x=thing1();     // statement1
x=thing2(x);    // statement2
doSomething(x); // statement3

Der Compiler kann möglicherweise Anweisung1 basierend auf der Tatsache optimieren, dass die Ausführung von Anweisung2 vor Anweisung3 garantiert ist. Wenn der Compiler erkennt, dass thing1 keine Nebenwirkungen hat und thing2 x nicht verwendet, kann er thing1 sicher ganz weglassen. Wenn [wie in diesem Fall] thing1 teuer wäre, könnte dies eine wesentliche Optimierung sein, obwohl die Fälle, in denen thing1 teuer ist, auch diejenigen sind, die der Compiler am wenigsten optimieren würde. Angenommen, der Code wurde geändert:

x=thing1();      // statement1
try
{ x=thing2(x); } // statement2
catch { q(); }
doSomething(x);  // statement3

Jetzt gibt es eine Folge von Ereignissen, bei denen Anweisung3 ausgeführt werden könnte, ohne dass Anweisung2 ausgeführt wurde. Selbst wenn nichts im Code für thing2eine Ausnahme Interlocked.CompareExchangeauslösen könnte, könnte ein anderer Thread eine verwenden, um zu bemerken, dass qgelöscht und auf gesetzt wurde Thread.ResetAbort, und dann eine Thread.Abort()Voranweisung ausführen, in die Anweisung2 ihren Wert geschrieben hat x. Dann catchwürde das Thread.ResetAbort()[über einen Delegaten q] ausgeführt, so dass die Ausführung mit Anweisung3 fortgesetzt werden kann. Eine solche Abfolge von Ereignissen wäre natürlich außerordentlich unwahrscheinlich, aber ein Compiler muss Code generieren, der gemäß der Spezifikation funktioniert, selbst wenn solche unwahrscheinlichen Ereignisse auftreten.

Im Allgemeinen ist es viel wahrscheinlicher, dass der Compiler Möglichkeiten bemerkt, einfache Codebits wegzulassen als komplexe, und daher ist es selten, dass ein Versuch / Fang die Leistung stark beeinträchtigt, wenn niemals Ausnahmen ausgelöst werden. Es gibt jedoch einige Situationen, in denen das Vorhandensein eines Try / Catch-Blocks Optimierungen verhindern kann, die - ohne Try / Catch - eine schnellere Ausführung des Codes ermöglicht hätten.

Obwohl " Prävention besser ist als Handhabung ", könnten wir im Hinblick auf Leistung und Effizienz den Try-Catch der Pre-Varication vorziehen. Betrachten Sie den folgenden Code:

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 1; i < int.MaxValue; i++)
{
    if (i != 0)
    {
        int k = 10 / i;
    }
}
stopwatch.Stop();
Console.WriteLine($"With Checking: {stopwatch.ElapsedMilliseconds}");
stopwatch.Reset();
stopwatch.Start();
for (int i = 1; i < int.MaxValue; i++)
{
    try
    {
        int k = 10 / i;
    }
    catch (Exception)
    {

    }
}
stopwatch.Stop();
Console.WriteLine($"With Exception: {stopwatch.ElapsedMilliseconds}");

Hier ist das Ergebnis:

With Checking: 20367
With Exception: 13998

In der Diskussion zur Try / Catch-Implementierung finden Sie eine Diskussion darüber, wie Try / Catch-Blöcke funktionieren und wie einige Implementierungen einen hohen Overhead und andere keinen Overhead haben, wenn keine Ausnahmen auftreten. Insbesondere denke ich, dass die Windows 32-Bit-Implementierung einen hohen Overhead hat und die 64-Bit-Implementierung nicht.