c++ - usar - ¿El bloque try-catch reduce el rendimiento
try catch finally c# (5)
Esta pregunta ya tiene una respuesta aquí:
Este link dice:
Para detectar excepciones, debemos colocar una porción de código bajo inspección de excepción. Esto se hace al encerrar esa porción de código en un bloque try. Cuando se produce una circunstancia excepcional dentro de ese bloque, se lanza una excepción que transfiere el control al manejador de excepciones. Si no se lanza ninguna excepción, el código continúa normalmente y todos los manejadores se ignoran.
¿Significa que tener un bloque de prueba reduce el rendimiento debido a la tarea adicional de "inspección" durante el tiempo de ejecución?
Depende. Para el manejo de excepciones, el compilador tiene que hacer algo; de lo contrario, no podría deshacerse de la pila y demás. Eso significa que sí, el manejo de excepciones disminuye el rendimiento, incluso si la excepción no se produce. Cuánto: esto depende de la implementación de tu compilador.
Por otro lado, debes hacerte la misma pregunta: si insertas tu código de manejo de errores por tu cuenta, ¿sería realmente más rápido? Mídelo, no lo adivines. ¿Puede hacer lo mismo que las excepciones (las excepciones no pueden ser ignoradas por el cliente? Los códigos de error pueden) y pueden hacer un stackunwinding que los códigos de error no pueden). Además, el código se puede escribir para que sea más fácil de mantener con excepciones.
Corto: a menos que su código sea muy, muy muy, muy, muy crítico en el tiempo, use excepciones. Incluso si decides contra ellos: mide primero. Una excepción a la regla: es una mala idea lanzar excepciones a través de los límites del módulo o en un destructor.
Eche un vistazo a la Sección 5.4 del borrador del Informe técnico sobre el rendimiento de C ++, que trata específicamente de la sobrecarga de las declaraciones try-catch en c ++.
Un pequeño extracto de la sección:
5.4.1.1.2 Tiempo de sobrecarga del enfoque de "Código"
• On entry to each try-block
♦ Commit changes to variables enclosing the try-block
♦ Stack the execution context
♦ Stack the associated catch clauses
• On exit from each try-block
♦ Remove the associated catch clauses
♦ Remove the stacked execution context
• When calling regular functions
♦ If a function has an exception-specification, register it for checking
• As local and temporary objects are created
♦ Register each one with the current exception context as it is created
• On throw or re-throw
♦ Locate the corresponding catch clause (if any) – this involves some runtime check (possibly resembling RTTI checks)
If found, then:
destroy the registered local objects
check the exception-specifications of the functions called in-between
use the associated execution context of the catch clause
Otherwise:
call the terminate_handler6
Realmente depende del compilador específico.
Si el compilador prefiere considerar la excepción arrojando una condición realmente excepcional, entonces puede implementar un esquema donde, en caso de que no exista una excepción, tiene cero sobrecarga pero eso, a su vez, le costará más tiempo en caso de excepción y / o más tamaño de código. .
Para implementar un enfoque de cero gastos generales, puede observar que en C ++ no puede cambiar el código de forma dinámica, así que una vez que sepa qué es el marco de pila y la dirección de retorno, se resuelve cuáles son los objetos que se deben destruir en caso de desenrollarse o si hay sección de código de manejo de excepciones. Por lo tanto, el código para lanzar una excepción podría verificar una tabla global de todos los sitios de llamadas de función para decidir qué se debe hacer.
Por otro lado, puede hacer que la excepción sea más rápida al preparar la lista de objetos que se destruirán explícitamente y la dirección del código de manejo de excepciones durante la ejecución normal. Esto hará que el código regular sea más lento, pero el manejo de excepciones sea más rápido y también diría que el código es un poco más pequeño.
Desafortunadamente no hay una forma estándar en C ++ de abandonar por completo el soporte de excepción, así que hay que tener en cuenta esta posibilidad: la biblioteca estándar arroja excepciones y cualquier código que llame a código desconocido (por ejemplo, usando un puntero de función o llamando a un método virtual) prepárate para manejar una excepción.
Recomendaría agregar try catch en funciones que hacen asignación de memoria, eliminación, llamando a otras funciones complejas, etc. En realidad, la captura de prueba de rendimiento agrega un poco de sobrecarga.
Pero teniendo en cuenta el mérito de atrapar las excepciones desconocidas, es muy útil. Las buenas prácticas de programación siempre recomiendan agregar algún tipo de manejo de excepciones en su código a menos que sea un programador excepcional.
Me pregunto por qué está tan preocupado por el pequeño problema de rendimiento que todo el programa con una excepción.
TL; DR NO , las excepciones suelen ser más rápidas en el camino no excepcional en comparación con el manejo del código de error.
Bueno, la observación obvia se compara con qué?
En comparación con no manejar el error, obviamente disminuye el rendimiento; pero el rendimiento vale la pena la falta de corrección? Yo diría que no, así que supongamos que quisiste decir comparado con un código de error marcado con una declaración if .
En este caso, depende. Existen múltiples mecanismos utilizados para implementar excepciones. En realidad, pueden implementarse con un mecanismo tan cercano a una declaración if que termine teniendo el mismo costo (o un poco más alto).
Sin embargo, en C ++, todos los compiladores principales (gcc lo introdujo en la serie 4.x, MSVC lo usa para el código de 64 bits) ahora usan el modelo de excepción de costo cero. Si lees este documento técnico vinculado a Need4Sleep, aparece como el enfoque basado en tablas. La idea es que, para cada punto del programa que pueda arrojarle, registre en una tabla lateral algunas partes que le permitirán encontrar la cláusula de captura correcta. Honestamente, es un poco más complicado de implementar que las estrategias anteriores, sin embargo, el nombre de Costo Cero se deriva del hecho de que es gratuito si no se lanza una excepción. Contraste esto con una predicción errónea de una sucursal en una CPU. Por otro lado, cuando se lanza una excepción, la penalización es enorme porque la tabla se almacena en una zona fría (por lo que probablemente se requiera un viaje de ida y vuelta a la memoria RAM o algo peor) ... pero las excepciones son excepcionales, ¿no?
En resumen, con los compiladores modernos de C ++ las excepciones son más rápidas que los códigos de error, a costa de binarios más grandes (debido a las tablas estáticas).