2010-02-02 14 views

Respuesta

11

¿Solo 5 veces más rápido? Tu me sorprendes Es de suponer que eso significa que sus datos de muestra no tienen muchos ceros.

Las excepciones son más caras que las comparaciones simples. Cuando se usan correctamente (es decir, para circunstancias excepcionales), no tienden a obstaculizar el rendimiento de manera significativa, porque si se lanzan suficientes excepciones para que tenga un gran impacto, es probable que su servicio ya esté contaminado. Es causa un problema cuando utiliza excepciones para tratar de ignorar condiciones que podría probar fácilmente para empezar, como esta.

Una cosa a tener en cuenta sobre el costo de las excepciones: cuestan mucho más en el depurador que cuando se ejecuta sin un depurador conectado; en particular, la primera excepción que necesita cargar un montón de recursos puede tomar segundos en lugar de micro/milisegundos. Si va a comparar el código, es vital que no lo haga en un depurador; eso es cierto en general, pero especialmente para las excepciones.

10

Porque las excepciones son caras.

Cuando se produce una excepción, el tiempo de ejecución necesita extraer bastante información (por ejemplo, seguimientos de pila) y hacerlos burbujear. Esto lleva tiempo y recursos, cuando una prueba de valor 0 es muy barata en comparación.

Consulte this SO question preguntando qué tan costosas son las excepciones para obtener más información.

5

Err, porque las excepciones son más lentas que la comprobación. Las excepciones generalmente tienen mucha infraestructura a su alrededor que una simple declaración if no tiene.

No son operaciones equivalentes ya que tiene mucha información entregada en una excepción incluso si elige no usarla como en este caso.

3

¿Por qué las excepciones son lentas?

Porque muchas cosas suceden cuando se lanza y atrapa una excepción. Vea Chris Brumme's post about the managed exception model y this post about the underlying Win32 SEH model para más detalles.

¿Por qué es una prueba simple rápida?

Porque simplemente ejecuta una instrucción para saltar dependiendo del resultado de la comparación de dos enteros, que es mucho menos trabajo que una excepción.

¿Eso significa que siempre debo tratar de evitar las excepciones?

No, depende de la semántica. Si dividir por cero es un caso realmente excepcional que no espera que suceda, y que su programa no puede manejar razonablemente, entonces permita que ocurra la excepción y bloquee su programa.Sin embargo, si se trata de un caso esperado y puede manejarlo de manera razonable, parece razonable evitar la excepción.

1

Las excepciones son extremadamente lento - Esta es la razón por la que el marco .Net tiene métodos TryParse:

// This is much quicker... 
double result; 
if (!double.TryParse("Twelve", out result)) 
{ 
    result = -1; 
} 
return result; 

// Than this... 
try 
{ 
    return double.Parse("Twelve"); 
} 
catch 
{ 
    return -1; 
} 

siempre debe intentar y evitar excepciones (excepto en circunstancias excepcionales - jaja ...)

Cuestiones relacionadas