I blocchi di prova / cattura danneggiano le prestazioni quando non vengono generate eccezioni?

Durante una revisione del codice con un dipendente Microsoft ci siamo imbattuti in un'ampia sezione di codice all'interno di un try{}blocco. Lei e un rappresentante IT hanno suggerito che ciò può avere effetti sulle prestazioni del codice. In effetti, hanno suggerito che la maggior parte del codice dovrebbe essere al di fuori dei blocchi try / catch e che dovrebbero essere verificate solo sezioni importanti. Il dipendente Microsoft ha aggiunto e ha affermato che un prossimo white paper mette in guardia contro blocchi di prova / cattura errati.

Mi sono guardato intorno e ho scoperto che può influire sulle ottimizzazioni , ma sembra applicarsi solo quando una variabile è condivisa tra ambiti.

Non sto chiedendo della manutenibilità del codice, o nemmeno gestendo le giuste eccezioni (il codice in questione ha bisogno di essere ripreso, senza dubbio). Inoltre non mi riferisco all'utilizzo di eccezioni per il controllo del flusso, questo è chiaramente sbagliato nella maggior parte dei casi. Quelle sono questioni importanti (alcune sono più importanti), ma non l'attenzione qui.

In che modo i blocchi try / catch influiscono sulle prestazioni quando non vengono generate eccezioni ?

Controllalo.

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

Produzione:

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

In millisecondi:

449
416

Nuovo codice:

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

Nuovi risultati:

   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

Dopo aver visto tutte le statistiche per con try / catch e senza try / catch, la curiosità mi ha costretto a guardare dietro per vedere cosa viene generato per entrambi i casi. Ecco il codice:

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

Non sono un esperto di IL ma possiamo vedere che un oggetto di eccezione locale viene creato sulla quarta riga .locals init ([0] class [mscorlib]System.Exception ex)dopo che le cose sono piuttosto le stesse del metodo senza provare / catturare fino alla diciassette riga IL_0021: leave.s IL_002f. Se si verifica un'eccezione, il controllo passa alla riga, IL_0025: ldloc.0altrimenti passiamo all'etichetta IL_002d: leave.s IL_002fe la funzione ritorna.

Posso tranquillamente presumere che se non si verificano eccezioni, è il sovraccarico della creazione di variabili locali per contenere solo oggetti eccezione e un'istruzione jump.

No. Se le banali ottimizzazioni che un blocco try / finally preclude in realtà hanno un impatto misurabile sul programma, probabilmente non dovresti usare .NET in primo luogo.

Spiegazione abbastanza completa del modello di eccezione .NET.

Tidbits sulle prestazioni di Rico Mariani: costo eccezionale: quando lanciare e quando non farlo

Il primo tipo di costo è il costo statico della gestione delle eccezioni nel codice. Le eccezioni gestite in realtà funzionano relativamente bene qui, il che significa che il costo statico può essere molto più basso di quanto si pensi in C ++. Perchè è questo? Bene, il costo statico è realmente sostenuto in due tipi di luoghi: in primo luogo, i siti reali di try / finally / catch / throw dove c'è codice per quei costrutti. In secondo luogo, nel codice non modificato, c'è il costo invisibile associato al tenere traccia di tutti gli oggetti che devono essere distrutti nel caso in cui venga generata un'eccezione. C'è una notevole quantità di logica di pulizia che deve essere presente e la parte subdola è che anche il codice che non

Dmitriy Zaslavskiy:

Secondo la nota di Chris Brumme: esiste anche un costo legato al fatto che alcune ottimizzazioni non vengono eseguite da JIT in presenza di catture

La struttura è diversa nell'esempio da Ben M . Sarà esteso in testa all'internofor ciclo che non farà un buon confronto tra i due casi.

Quanto segue è più accurato per il confronto in cui l'intero codice da verificare (inclusa la dichiarazione delle variabili) si trova all'interno del blocco Try / Catch:

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

Quando ho eseguito il codice di test originale di Ben M , ho notato una differenza sia nella configurazione di Debug che in quella di Releas.

Questa versione, ho notato una differenza nella versione di debug (in realtà più rispetto all'altra versione), ma non c'era differenza nella versione di rilascio.

Conclution :
Sulla base di questi prova, penso che possiamo dire che try / catch ha avere un piccolo impatto sulle prestazioni.

EDIT:
ho provato ad aumentare il valore del loop da 10000000 a 1000000000, e ho eseguito di nuovo in versione per ottenere alcune differenze nella versione, e il risultato è stato questo:

   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

Vedi che il risultato non è pertinente. In alcuni casi la versione che usa Try / Catch è in realtà più veloce!

Ho testato l'impatto effettivo di un try..catchcircuito chiuso, ed è troppo piccolo da solo per essere un problema di prestazioni in qualsiasi situazione normale.

Se il ciclo funziona molto poco (nel mio test ne ho fatto uno x++), puoi misurare l'impatto della gestione delle eccezioni. L'esecuzione del ciclo con gestione delle eccezioni ha richiesto circa dieci volte di più.

Se il ciclo funziona davvero (nel mio test ho chiamato il metodo Int32.Parse), la gestione delle eccezioni ha un impatto troppo scarso per essere misurabile. Ho ottenuto una differenza molto più grande scambiando l'ordine dei loop ...

provare a catturare i blocchi ha un impatto trascurabile sulle prestazioni ma l'eccezione Il lancio può essere piuttosto considerevole, probabilmente è qui che il tuo collega era confuso.

Il tentativo / cattura ha un impatto sulle prestazioni.

Ma non è un impatto enorme. la complessità try / catch è generalmente O (1), proprio come un semplice compito, tranne quando sono inseriti in un ciclo. Quindi devi usarli saggiamente.

Ecco un riferimento sulle prestazioni try / catch (non spiega la complessità, ma è implicito). Dai un'occhiata alla sezione Lancia meno eccezioni

In teoria, un blocco try / catch non avrà alcun effetto sul comportamento del codice a meno che non si verifichi effettivamente un'eccezione. Ci sono alcune rare circostanze, tuttavia, in cui l'esistenza di un blocco try / catch può avere un effetto maggiore, e alcune non comuni ma quasi oscure in cui l'effetto può essere evidente. La ragione di ciò è che quel codice dato come:

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

il compilatore potrebbe essere in grado di ottimizzare statement1 in base al fatto che statement2 è garantito per essere eseguito prima di statement3. Se il compilatore è in grado di riconoscere che cosa1 non ha effetti collaterali e cosa2 in realtà non usa x, può tranquillamente omettere del tutto cosa1. Se [come in questo caso] cosa1 fosse costoso, questa potrebbe essere una grande ottimizzazione, anche se i casi in cui cosa1 è costoso sono anche quelli che il compilatore avrebbe meno probabilità di ottimizzare. Supponiamo che il codice sia stato modificato:

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

Ora esiste una sequenza di eventi in cui statement3 potrebbe essere eseguito senza aver eseguito statement2. Anche se nulla nel codice per thing2potrebbe generare un'eccezione, sarebbe possibile che un altro thread potesse usare un Interlocked.CompareExchangeper notare che è qstato cancellato e impostato su Thread.ResetAbort, e quindi eseguire Thread.Abort()un'istruzione before2 in cui ha scritto il suo valore x. Quindi catcheseguirà Thread.ResetAbort()[tramite delegato q], consentendo l'esecuzione per continuare con statement3. Una tale sequenza di eventi sarebbe ovviamente eccezionalmente improbabile, ma è necessario un compilatore per generare codice che funzioni secondo le specifiche anche quando si verificano tali eventi improbabili.

In generale, il compilatore ha molte più probabilità di notare opportunità di tralasciare semplici bit di codice rispetto a quelli complessi, e quindi sarebbe raro che un tentativo / cattura possa influire molto sulle prestazioni se non vengono mai generate eccezioni. Tuttavia, ci sono alcune situazioni in cui l'esistenza di un blocco try / catch potrebbe impedire ottimizzazioni che - ma per il tentativo / catch - avrebbero permesso al codice di funzionare più velocemente.

Sebbene " Prevenire sia meglio che maneggiare ", nella prospettiva delle prestazioni e dell'efficienza potremmo scegliere il metodo di prova rispetto alla pre-varicazione. Considera il codice seguente:

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

Ecco il risultato:

With Checking: 20367
With Exception: 13998

Vedi la discussione sull'implementazione try / catch per una discussione su come funzionano i blocchi try / catch e su come alcune implementazioni hanno un overhead elevato e altre hanno overhead zero, quando non si verificano eccezioni. In particolare, penso che l'implementazione di Windows a 32 bit abbia un overhead elevato, e l'implementazione a 64 bit no.