2011-11-24 10 views
6

¿Cuánto tiempo más (en nanosegundos) tarda un try-catch cuando se captura una excepción en lugar de hacer una comprobación (suponiendo que el mensaje tenga el rendimiento del tipo HashMap para la búsqueda)?Prueba Catch Performance Java

try { 
     timestamp = message.getLongField(MessageField.TIMESTAMP); 
    } catch (MissingDataException e) { 
     //Not all messages contain this field 
    } 

vs

if (message.contains(MessageField.TIMESTAMP)) 
    timestamp = message.getLongField(MessageField.TIMESTAMP); 
+0

Variará mucho la base de JVM, el hardware subyacente, etc. ¿Has intentado medirlo tú mismo? – Sean

+1

¿Es eso una situación excepcional? ¿Necesita registrarlo como un error? ¿Este código se ejecuta en un bucle? –

+0

Possilbe duplicado: http://stackoverflow.com/questions/4280831/java-try-catch-performance-is-it-recommended-to-keep-what-is-inside-the-try-cla & http: // stackoverflow.com/questions/5158665/java-try-catch-blocks –

Respuesta

22

En resumen, el cheque es manera más rápido. Debe usar el cheque porque:

  • ¡Las excepciones son CAROÑAS! Debe crearse una traza de pila (si se usa, por ejemplo, registrada, etc.) y control de flujo especial manejado
  • Las excepciones no se deben usar para control de flujo - Las excepciones son para el "excepcional"
  • Las excepciones son la forma del código de decir "I no puede manejar esta situación y yo estoy rindiendo ... tratar con él!", pero aquí se puede manejarlo ... así que lo maneja
+0

En algunas circunstancias, la excepción puede optimizarse, por lo que no es necesariamente más lenta en todos los casos. –

+2

+1: El seguimiento de la pila no se crea completamente hasta que se usa (como para la mayoría de las excepciones no es necesario) Las mismas excepciones no son solo costosas, sino que deben ser para condiciones excepcionales. –

+0

@PeterLawrey Gracias - No sabía que no se crearon stacktraces hasta que se usó – Bohemian

3

la respuesta es "mucho más tiempo". Las excepciones son lentas en comparación con un cheque debido al tiempo para construir la stacktrace.

Como punto general, usar excepciones para controlar el flujo del programa es una mala idea ya que desordena el código. Siempre haga el control y deje excepciones cuando ocurran cosas "excepcionales".

+0

Me gustaría cuantificar esto ... –

+0

En algunas circunstancias, la excepción puede optimizarse, por lo que no es necesariamente más lenta en todos los casos. –

3

Otra respuesta es 'a quién le importa!' . ¡Está incorrecto!

En cualquier caso, si desea establecer criterios de referencia, utilice https://github.com/google/caliper

+0

¿Alguien hizo esto? Supongo que el costo de try es trivial, el costo de throw (e) ... catch (Exception e) {} es bastante caro, por lo que solo se debe usar el constructo para situaciones poco frecuentes (es decir, excepcionales). pero ¿cómo funciona una "prueba" en relación con permite decir una prueba (si (x)), agregar (i + = j), etc. Creo que en algún lugar en maype 1 a 5x esa cantidad si se implementa bien. – peterk

+0

¿Todavía se mantiene la pinza? en mi caso arroja un 'NoSuchMethodError' – Joel

+0

Parece que se ha movido a Github. Actualizado el enlace – alex

1

¿Le gustaría cuantificar este ...

Es literalmente imposible de cuantificar en general. No en nanosegundos ... porque depende de la plataforma de ejecución. Y ni siquiera en términos porcentuales.

El tiempo depende en gran medida del tiempo necesario para capturar el seguimiento de la pila, y que depende de la profundidad de la pila cuando se produce la excepción. Y esa es solo una de las razones por las que el uso de excepciones Java en lugar de declaraciones condicionales regulares es una muy mala idea.

Pero la otra cara es que hay alcance para el compilador JIT que en gran medida a optimizar el código relacionado con excepción proporciona que puede determinar que el seguimiento de la pila para y excepción lanzada en un punto particular nunca va a ser usado.


Si realmente desea algunos números (OMI, sin sentido y en gran medida sin sentido), que tendrá que hacer su propia evaluación comparativa. Buena suerte.