¿Es costoso usar bloques try-catch incluso si nunca se lanza una excepción?

Sabemos que es costoso detectar excepciones. Pero, ¿también es costoso usar un bloque try-catch en Java incluso si nunca se lanza una excepción?

Encontré la pregunta / respuesta Stack Overflow ¿Por qué los bloques de prueba son caros? , pero es para .NET .

trycasi no tiene gastos en absoluto. En lugar de hacer el trabajo de configurar el trytiempo de ejecución, los metadatos del código se estructuran en el momento de la compilación de modo que cuando se produce una excepción, ahora se realiza una operación relativamente costosa de subir la pila y ver si hay algunotry existen bloques que atrapen esto excepción. Desde la perspectiva de un laico, bien trypodría ser libre. En realidad, arrojar la excepción es lo que le cuesta, pero a menos que esté lanzando cientos o miles de excepciones, aún no notará el costo.

trytiene algunos costos menores asociados. Java no puede hacer algunas optimizaciones en el código en un trybloque que de otro modo haría. Por ejemplo, Java a menudo reorganizará las instrucciones en un método para que se ejecute más rápido, pero Java también debe garantizar que si se produce una excepción, la ejecución del método se observa como si sus declaraciones, tal como están escritas en el código fuente, se ejecuten en orden hasta alguna línea.

¡Porque en un trybloque se puede lanzar una excepción (en cualquier línea en el bloque de prueba! Algunas excepciones se lanzan de forma asincrónica, como llamar stopa un Thread (que está en desuso), e incluso además, OutOfMemoryError puede suceder casi en cualquier lugar) y, sin embargo, puede detectarse y el código continúa ejecutándose después con el mismo método, es más difícil razonar sobre las optimizaciones que se pueden hacer, por lo que es menos probable que sucedan. (Alguien tendría que programar el compilador para que lo haga, razonar y garantizar la corrección, etc. Sería un gran dolor para algo destinado a ser 'excepcional') Pero una vez más, en la práctica no notará cosas como esta.

Vamos a medirlo, ¿de acuerdo?

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1;
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        try {
                            x += i;
                        } catch (Exception e) {
                            e.printStackTrace();
                        }
                    }
                    return x;
                }
            }, new Benchmark("no try") {
                @Override int run(int iterations) throws Throwable {
                    int x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x += i;
                    }
                    return x;
                }
            }
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

En mi computadora, esto imprime algo como:

try     0.598 ns
no try  0.601 ns

Al menos en este ejemplo trivial, la declaración try no tuvo un impacto medible en el rendimiento. Siéntase libre de medir los más complejos.

En términos generales, recomiendo no preocuparse por el costo de rendimiento de las construcciones de lenguaje hasta que tenga evidencia de un problema de rendimiento real en su código. O como dijo Donald Knuth : "la optimización prematura es la raíz de todo mal".

try/ catchpuede tener algún impacto en el rendimiento. Esto se debe a que evita que JVM haga algunas optimizaciones. Joshua Bloch, en "Java efectivo", dijo lo siguiente:

• Colocar el código dentro de un bloque try-catch inhibe ciertas optimizaciones que las implementaciones modernas de JVM de otro modo podrían realizar.

Sí, como han dicho los demás, un trybloque inhibe algunas optimizaciones en los {}personajes que lo rodean. En particular, el optimizador debe asumir que podría ocurrir una excepción en cualquier punto dentro del bloque, por lo que no hay garantía de que las declaraciones se ejecuten.

Por ejemplo:

    try {
        int x = a + b * c * d;
        other stuff;
    }
    catch (something) {
        ....
    }
    int y = a + b * c * d;
    use y somehow;

Sin el try, el valor calculado para asignar a xpodría guardarse como una "subexpresión común" y reutilizarse para asignar a y. Pero debido a que tryno hay garantía de que la primera expresión haya sido evaluada, entonces la expresión debe ser recalculada. Esto no suele ser un gran problema en el código de "línea recta", pero puede ser significativo en un bucle.

Sin embargo, debe tenerse en cuenta que esto se aplica SOLO al código JITCed. javac solo realiza una pequeña cantidad de optimización, y el intérprete de bytecode tiene un costo cero para ingresar / salir de un trybloque. (No se generan bytecodes para marcar los límites del bloque).

Y para bestsss:

public class TryFinally {
    public static void main(String[] argv) throws Throwable {
        try {
            throw new Throwable();
        }
        finally {
            System.out.println("Finally!");
        }
    }
}

Salida:

C:\JavaTools>java TryFinally
Finally!
Exception in thread "main" java.lang.Throwable
        at TryFinally.main(TryFinally.java:4)

salida de javap:

C:\JavaTools>javap -c TryFinally.class
Compiled from "TryFinally.java"
public class TryFinally {
  public TryFinally();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]) throws java.lang.Throwable;
    Code:
       0: new           #2                  // class java/lang/Throwable
       3: dup
       4: invokespecial #3                  // Method java/lang/Throwable."<init>":()V
       7: athrow
       8: astore_1
       9: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      12: ldc           #5                  // String Finally!
      14: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      17: aload_1
      18: athrow
    Exception table:
       from    to  target type
           0     9     8   any
}

No "GOTO".

Para comprender por qué no se pueden realizar las optimizaciones, es útil comprender los mecanismos subyacentes. El ejemplo más sucinto que pude encontrar se implementó en macros C en: http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

#include <stdio.h>
#include <setjmp.h>
#define TRY do{ jmp_buf ex_buf__; switch( setjmp(ex_buf__) ){ case 0: while(1){
#define CATCH(x) break; case x:
#define FINALLY break; } default:
#define ETRY } }while(0)
#define THROW(x) longjmp(ex_buf__, x)

Los compiladores a menudo tienen dificultades para determinar si un salto se puede localizar en X, Y y Z, por lo que omiten las optimizaciones que no pueden garantizar que sean seguras, pero la implementación en sí es bastante ligera.

Sin embargo, otro microbenchmark ( fuente ).

Creé una prueba en la que mido la versión del código try-catch y no-try-catch según un porcentaje de excepción. El 10% de porcentaje significa que el 10% de los casos de prueba tenían división por cero casos. En una situación es manejado por un bloque try-catch, en la otra por un operador condicional. Aquí está mi tabla de resultados:

OS: Windows 8 6.2 x64
JVM: Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 23.25-b01

Porcentaje | Resultado (prueba / if, ns)   
    0% | 88/90   
    1% | 89/87    
    10% | 86/97    
    90% | 85/83   

Lo que dice que no hay una diferencia significativa entre ninguno de estos casos.

He encontrado la captura de NullPointException bastante costosa. Para las operaciones de 1.2k, el tiempo fue de 200ms y 12ms cuando lo manejé de la misma manera, lo if(object==null)que fue una mejora considerable para mí.