C# Real Time Try Catch

Me gustaría recibir una respuesta de alguien que realmente hace programación en tiempo real en C# o que realmente entienda el idioma interno.C# Real Time Try Catch

Sé que las excepciones no se deben usar para manejar el procesamiento normal, sino solo para detectar condiciones de error. Hay mucha discusión sobre ese tema.

Me gustaría saber si hay alguna ralentización del tiempo de ejecución simplemente por tener un bloque try/catch en su lugar (que nunca atrapa una excepción a menos que el programa tenga que terminar de todos modos). El bloque try/catch está dentro de una función que debe ser llamada repetidamente. Sospecho que solo hay un costo mínimo.

¿Se puede cuantificar el costo en términos de ciclos de CPU u otras tareas (el mismo costo que una multiplicación de coma flotante), o de otra manera?

Utilizamos Microsoft C# .Net 3.5 en Windows XP.

Fuente

2009-08-28 Mark T

Tome un vistazo a los recursos de Jon Skeet sobre las excepciones y el rendimiento: http://www.yoda.arachsys.com/csharp/exceptions.html –

. Las excepciones de .NET tienen un costo muy, muy bajo, a menos que sean arrojadas. Tener un bloque try/catch en su lugar tendrá un impacto mínimo en el rendimiento. No he encontrado casi ningún impacto, incluso en bucles muy rápidos y apretados, para tener el manejo de excepciones en su lugar.

Sin embargo, las excepciones en .NET son MUY caras cuando se lanzan. Tienden a tener un gran impacto en el rendimiento si los arrojas en muchos otros idiomas. Esto se debe a la información de pila completa obtenida cuando se crea la excepción, etc.

Este es el comportamiento opuesto a otros lenguajes, como python, donde el manejo de excepciones tiene un costo mayor, pero arrojar es en realidad bastante eficiente.

Sin embargo, si le preocupa, le sugiero que haga un perfil de su rutina y la pruebe usted mismo. Esta ha sido mi experiencia después de un buen perfil de rendimiento. No hay sustitución para medir en su propia base de código.

Fuente

2009-08-28 15:49:37

En realidad, un seguimiento de pila no se produce hasta que acceda a la La propiedad StackTrace, o si la excepción pasa un límite de proceso (es decir, remoting/wcf/etc.) Crear una excepción también es de muy bajo costo, ya que la construcción solo establece algunas propiedades. El proceso throw determina StackCrawlMarks que facilita el rastreo de la pila si se solicita StackTrace ... pero en .NET 2.0, el rastreo no ocurre en cada tiro a menos que realmente acceda a él. – jrista

Sí, en realidad me refería al mecanismo de marcado de pila, pero mi respuesta no era clara. Sin embargo, esto hace que, en mi perfil, tenga una sobrecarga bastante significativa (sin embargo, esto está asumiendo sistemas críticos). Rico Mariani tiene una buena publicación en el blog explicando por qué, pero para mí, el problema era el error de caché adicional y las fallas de página: http://blogs.msdn.com/ricom/archive/2006/09/25/771142.aspx –

Gracias para esa información. Desafortunadamente no tenemos las herramientas para perfilar nuestro código ... solo tenemos que seguir las mejores prácticas. –

Buena discusión, con métricas, de las implicaciones de rendimiento de try catch aquí.

Do try/catch blocks hurt performance when exceptions are not thrown?

Fuente

2009-08-28 15:57:29 Gratzy

Respuesta

Cuestiones relacionadas