De que forma exceções C ++ código lento para baixo quando não há exceções jogado?

Question

Eu li que há alguma sobrecarga ao uso de exceções C ++ para manipulação de exceção em oposição a, digamos, verificar valores de retorno. Eu só estou falando sobre a sobrecarga que se incorre quando nenhuma exceção é lançada. Eu também estou supondo que você precisa implementar o código que realmente verifica o valor de retorno e faz a coisa apropriada, qualquer que seja seria o equivalente ao que o bloco catch teria feito. E, também não é justo comparar o código que lança objetos de exceção com variáveis ??45 estaduais dentro de código que retorna um inteiro negativo para cada erro.

Eu não estou tentando construir um caso a favor ou contra exceções C ++ com base unicamente no que se pode executar mais rápido. Eu ouvi alguém fazer o caso recentemente que o código usando exceções deveria correr tão rápido quanto código com base nos códigos de retorno, uma vez que você levar em conta todo o código contabilidade extra que seria necessário para verificar os valores de retorno e lidar com os erros. O que eu estou ausente?

Answer 1

Há um custo associado com a manipulação de exceção em alguns plataformas e com alguns compiladores.

Ou seja, Visual Studio, quando a construção de um alvo de 32 bits, vai registrar um manipulador em cada função que tem variáveis ??locais com destrutor não-trivial. Basicamente, ele configura um manipulador try/finally.

A outra técnica, empregue por gcc e Visual Studio segmentação 64-bits, única incorre sobrecarga quando uma exceção é jogado (a técnica envolve a atravessar a pilha de chamadas e consulta à tabela). Nos casos em que as exceções são raramente jogadas, isso pode realmente levar a um código mais eficiente, como códigos de erro não tem que ser processado.

Answer 2

Apenas try / catch e tente / exceto bloco demorar algumas instruções para configurar. A sobrecarga deve geralmente ser insignificante em todos os casos, excepto as laçadas tighest. Mas você normalmente não usar try / catch / exceto em um loop interno de qualquer maneira.

Eu aconselharia não se preocupar com isso, e usar um profiler vez para otimizar seu código onde for necessário.

Answer 3

É completamente dependente de implementação, mas muitas implementações recentes têm muito pouco ou nenhum desempenho sobrecarga quando exceções não são lançadas. Na verdade, você está certo. Corretamente verificando os códigos de retorno de todas as funções no código que não usam exceções podem ser mais lento, em seguida, sem fazer nada para exceções de código usando.

Claro, você precisa medir o desempenho para suas necessidades particulares para ter certeza.

Answer 4

Não é alguma sobrecarga com exceções (como as outras respostas apontou).

Mas você não tem muita escolha hoje em dia. Tente fazer desativar exceções em seu projeto, e certifique-se que todo o código dependente e bibliotecas podem compilar e executar sem.

Será que eles trabalham com exceções desativada?

Vamos supor que eles fazem! Então referência alguns casos, mas nota que você tem que definir uma "desativar exceções" switch compilação. Sem essa chave, você ainda tem a sobrecarga - mesmo se o código não gera exceções

.

Answer 5

Apenas sobrecarga é ~ 6 instruções que adicionar 2 SEH no início da função e deixá-los no final. Não importa quantas try / capturas que você tem em um fio que é sempre o mesmo.

Também o que é isso sobre variáveis ??locais? Eu ouço as pessoas sempre a queixar-los ao usar try / catch. Eu não obtê-lo, porque os desconstrutores acabaria por ser chamado de qualquer maneira. Além disso, você não deve estar deixando uma exceção subir mais de 1-3 chamadas.

Answer 6

Eu levei o código de teste de Chip Uni e expandiu-lo um pouco. I dividir o código em dois arquivos de origem (um com exceções, um sem). Eu fiz cada benchmark executar 1000 vezes, e eu usei clock_gettime() com CLOCK_REALTIME para registrar as horas de início e fim de cada iteração. Então eu calculado a média ea variância dos dados. Corri este teste com versões de 64 bits do g ++ 5.2.0 e clang ++ 3.7.0 sobre uma caixa de processador Intel Core i7 com 16GB RAM que corre ArchLinux com o kernel 4.2.5-1-ARCH. Você pode encontrar o código expandido e os resultados completos aqui .

g ++

sem exceções

• Média: 30,022,994 nanossegundos
• Desvio Padrão: 1.25327e + 06 nanossegundos

exceções

• Média: 30,025,642 nanossegundos
• Desvio Padrão: 1.83422e + 06 nanossegundos

clang ++

sem exceções

• Média: 20,954,657 nanossegundos
• Desvio Padrão: 426,662 nanossegundos

exceções

• Média: 23,916,638 nanossegundos
• Desvio Padrão: 1.72583e + 06 nanossegundos

Excepções C ++ única uma penalidade desempenho não trivial com tinido ++, e até que a penalidade é apenas ~ 14%.