Est-il coûteux à l'utilisation de blocs try-catch, même si une exception n'est jamais jeté?

Mesurons il, allons-nous?

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);
}
}
}

Sur mon ordinateur, cela s'imprime quelque chose comme:

try     0.598 ns
no try  0.601 ns

Au moins dans cet exemple trivial, le rapport d'essai n'avait aucun impact mesurable sur la performance. Se sentir libre de mesure plus complexes.

Une manière générale, je recommande de ne pas vous soucier de la performance des coûts de constructions de langage jusqu'à ce que vous avez des preuves de rendement réel problème dans votre code. Ou comme Donald Knuth mettre: "l'optimisation prématurée est la racine de tout mal".

OriginalL'auteur meriton

Yep, comme les autres l'ont dit, un try bloc inhibe certaines optimisations à travers le {} personnages qui l'entourent. En particulier, l'optimiseur doit supposer qu'une exception peut se produire à n'importe quel point à l'intérieur du bloc, donc il n'y a aucune assurance que les instructions sont exécutées.

Par exemple:

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

Sans try, la valeur calculée à attribuer à x a pu être sauvé comme un "sous-expression" et réutilisés à attribuer à y. Mais en raison de la try il n'y a aucune assurance que la première expression n'a jamais été évalué, de sorte que l'expression doit être recalculé. Ce n'est généralement pas un gros problème en "ligne droite" de code, mais peuvent être importants dans une boucle.

Il convient de noter, toutefois, que cela ne s'applique qu'à JITCed code. javac ne fait qu'un minable montant de l'optimisation, et il y a un coût nul pour l'interpréteur de bytecode pour entrer/quitter un try bloc. (Il n'y a pas bytecode généré pour marquer les limites des blocs.)

Et pour bestsss:

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

De sortie:

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

javap de sortie:

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
}

Pas de "GOTO".

OriginalL'auteur Hot Licks

De comprendre pourquoi les optimisations ne peut pas être effectuée, Il est utile de comprendre les mécanismes sous-jacents. La plus succincte exemple que j'ai pu trouver a été implémenté en C macros: 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)

Compilateurs ont souvent de la difficulté à déterminer si un saut peut être localisée à X, Y et Z de sorte qu'ils sauter les optimisations qu'ils ne peuvent pas garantir d'être en sécurité, mais la mise en œuvre elle-même est plutôt léger.

OriginalL'auteur technosaurus