Os blocos try / catch prejudicam o desempenho quando exceções não são lançadas?

Durante uma revisão de código com um funcionário da Microsoft, encontramos uma grande seção de código dentro de um try{}bloco. Ela e um representante de TI sugeriram que isso pode ter efeitos no desempenho do código. De fato, eles sugeriram que a maior parte do código deveria estar fora dos blocos try / catch e que somente seções importantes deveriam ser verificadas. O funcionário da Microsoft acrescentou e disse que um próximo informe técnico adverte contra blocos de tentativa / captura incorretos.

Eu olhei em volta e descobri que isso pode afetar as otimizações , mas parece se aplicar apenas quando uma variável é compartilhada entre escopos.

Não estou perguntando sobre a manutenção do código, ou mesmo sobre as exceções corretas (o código em questão precisa ser refatorado, sem dúvida). Também não estou me referindo ao uso de exceções para controle de fluxo, isso é claramente errado na maioria dos casos. Essas são questões importantes (algumas são mais importantes), mas não o foco aqui.

Como os blocos try / catch afetam o desempenho quando exceções não são lançadas?

Verifique-o.

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

Resultado:

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

Em milissegundos:

449
416

Novo Código:

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

Novos resultados:

   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

Depois de ver todas as estatísticas de try / catch e sem try / catch, a curiosidade me forçou a olhar para trás para ver o que é gerado para os dois casos. Aqui está o código:

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

Eu não sou especialista em IL, mas podemos ver que um objeto de exceção local é criado na quarta linha .locals init ([0] class [mscorlib]System.Exception ex)depois que as coisas são praticamente as mesmas do método sem try / catch até a linha dezessete IL_0021: leave.s IL_002f. Se ocorrer uma exceção, o controle saltará para a linha, IL_0025: ldloc.0caso contrário, saltaremos para o rótulo IL_002d: leave.s IL_002fe a função retorna.

Posso assumir com segurança que, se nenhuma exceção ocorrer, será a sobrecarga da criação de variáveis ​​locais para armazenar apenas objetos de exceção e uma instrução de salto.

Não. Se as otimizações triviais que um bloco try / finalmente impedem realmente têm um impacto mensurável em seu programa, você provavelmente não deve usar o .NET em primeiro lugar.

Explicação bastante abrangente do modelo de exceção .NET.

Petiscos de desempenho de Rico Mariani: Custo de exceção: Quando jogar e quando não

O primeiro tipo de custo é o custo estático de se tratar de exceção no seu código. As exceções gerenciadas realmente são comparativamente bem aqui, o que significa que o custo estático pode ser muito menor do que o C ++. Por que é isso? Bem, o custo estático é realmente incorrido em dois tipos de locais: primeiro, os sites reais de try / finalmente / catch / throw onde há código para essas construções. Segundo, no código não gerenciado, há o custo oculto associado ao rastreamento de todos os objetos que devem ser destruídos no caso de uma exceção ser lançada. Há uma quantidade considerável de lógica de limpeza que deve estar presente, e a parte sorrateira é que mesmo o código que não '

Dmitriy Zaslavskiy:

Conforme nota de Chris Brumme: Há também um custo relacionado ao fato de alguma otimização não estar sendo realizada pelo JIT na presença de captura

A estrutura é diferente, no exemplo de Ben M . Ele será estendido acima do forloop interno, o que fará com que não seja uma boa comparação entre os dois casos.

A seguir, é mais preciso para comparação, onde todo o código a ser verificado (incluindo declaração de variável) está dentro do bloco 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 executei o código de teste original de Ben M , notei uma diferença nas configurações Debug e Releas.

Nesta versão, notei uma diferença na versão de depuração (na verdade mais do que a outra versão), mas não houve diferença na versão de lançamento.

Conclution :
Com base nestes testes, acho que podemos dizer que try / catch faz ter um pequeno impacto no desempenho.

EDIT:
Tentei aumentar o valor do loop de 10000000 para 1000000000 e executei novamente no Release para obter algumas diferenças no release, e o resultado foi o seguinte:

   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

Você vê que o resultado é inconseqüente. Em alguns casos, a versão usando Try / Catch é realmente mais rápida!

Testei o impacto real de um try..catchcircuito fechado e ele é pequeno demais para ser uma preocupação de desempenho em qualquer situação normal.

Se o loop fizer muito pouco trabalho (no meu teste que fiz x++), você poderá medir o impacto do tratamento de exceções. O loop com manipulação de exceção demorou cerca de dez vezes mais para ser executado.

Se o loop executar algum trabalho real (no meu teste, chamei o método Int32.Parse), o tratamento de exceções terá muito pouco impacto para ser mensurável. Eu tenho uma diferença muito maior trocando a ordem dos loops ...

Os blocos try catch têm um impacto insignificante no desempenho, mas a exceção Arremesso pode ser bastante considerável, provavelmente é aí que seu colega de trabalho ficou confuso.

A tentativa / captura tem impacto no desempenho.

Mas não é um grande impacto. a complexidade try / catch é geralmente O (1), como uma atribuição simples, exceto quando são colocadas em um loop. Então você tem que usá-los com sabedoria.

Aqui está uma referência sobre o desempenho try / catch (embora não explique a complexidade, mas está implícito). Dê uma olhada na seção Lançar Menos Exceções

Em teoria, um bloco try / catch não terá efeito no comportamento do código, a menos que uma exceção realmente ocorra. Existem algumas circunstâncias raras, no entanto, em que a existência de um bloco de tentativa / captura pode ter um efeito importante, e outras incomuns, mas dificilmente obscuras, nas quais o efeito pode ser perceptível. A razão para isso é que o código fornecido, como:

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

o compilador pode otimizar a instrução1 com base no fato de que a instrução2 é executada antes da instrução3. Se o compilador puder reconhecer que o item1 não tem efeitos colaterais e o item2 não usa x, ele pode omitir completamente o item1. Se [como neste caso] a coisa1 for cara, isso pode ser uma grande otimização, embora os casos em que a coisa1 seja cara também sejam aqueles em que o compilador provavelmente menos otimizará. Suponha que o código tenha sido alterado:

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

Agora existe uma sequência de eventos em que a instrução3 poderia ser executada sem a instrução2 ter sido executada. Mesmo que nada no código for thing2capaz de gerar uma exceção, seria possível que outro thread pudesse usar um Interlocked.CompareExchangepara perceber que qfoi limpo e configurá-lo como Thread.ResetAbort, e então executar uma Thread.Abort()instrução before2 que escreveu seu valor em x. Então o catchseria executado Thread.ResetAbort()[via delegado q], permitindo que a execução continuasse com a instrução3. É claro que essa sequência de eventos seria excepcionalmente improvável, mas é necessário um compilador para gerar código que funcione de acordo com as especificações, mesmo quando esses eventos improváveis ​​ocorrem.

Em geral, é muito mais provável que o compilador perceba oportunidades de deixar de fora pedaços simples de código que códigos complexos e, portanto, seria raro uma tentativa / captura afetar o desempenho muito se exceções nunca forem lançadas. Ainda assim, existem algumas situações em que a existência de um bloco try / catch pode impedir otimizações que - mas para o try / catch - teriam permitido que o código fosse executado mais rapidamente.

Embora " Prevenir é melhor que manipular ", na perspectiva de desempenho e eficiência, poderíamos escolher o try-catch sobre a pré-varicação. Considere o código abaixo:

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

Aqui está o resultado:

With Checking: 20367
With Exception: 13998

Consulte a discussão sobre a implementação try / catch para obter uma discussão sobre como os blocos try / catch funcionam e como algumas implementações têm sobrecarga alta e outras zero, quando nenhuma exceção ocorre. Em particular, acho que a implementação do Windows de 32 bits tem uma sobrecarga alta e a implementação de 64 bits não.