Java Reflection : Pourquoi est-ce si lent ?

Question

J'ai toujours évité les réflexions en Java, uniquement en raison de sa réputation de lenteur. J'ai atteint un point dans la conception de mon projet actuel où être capable de l'utiliser rendrait mon code beaucoup plus lisible et élégant, alors j'ai décidé de l'essayer.

J'ai été tout simplement étonné par la différence, j'ai remarqué des temps d'exécution parfois presque 100x plus longs. Même dans cet exemple simple où il suffit d'instancier une classe vide, c'est incroyable.

class B {

}

public class Test {

    public static long timeDiff(long old) {
        return System.currentTimeMillis() - old;
    }

    public static void main(String args[]) throws Exception {

        long numTrials = (long) Math.pow(10, 7);

        long millis;

        millis = System.currentTimeMillis();

        for (int i=0; i<numTrials; i++) {
            new B();
        }
        System.out.println("Normal instaniation took: "
                 + timeDiff(millis) + "ms");

        millis = System.currentTimeMillis();

        Class<B> c = B.class;

        for (int i=0; i<numTrials; i++) {
            c.newInstance();
        }

        System.out.println("Reflecting instantiation took:" 
              + timeDiff(millis) + "ms");

    }
}

Donc en fait, mes questions sont

• Pourquoi est-ce si lent ? Y a-t-il quelque chose que je fais mal ? (même l'exemple ci-dessus montre la différence). J'ai du mal à croire que cela puisse vraiment être 100x plus lent qu'une instanciation normale.

• Y a-t-il quelque chose d'autre qui puisse être mieux utilisé pour traiter le code comme des données (n'oubliez pas que je suis coincé avec Java pour le moment) ?

Answer 1

La réflexion est lente pour quelques raisons évidentes :

1. Le compilateur ne peut effectuer aucune optimisation car il n'a aucune idée réelle de ce que vous faites. Cela vaut probablement pour le JIT également
2. Tout ce qui est invoqué/créé doit être a découvert (par exemple, recherche de classes par leur nom, recherche de méthodes correspondantes, etc.)
3. Les arguments doivent être mis en forme par le biais de la mise en boîte et de la mise hors boîte, de l'emballage dans des tableaux, Exceptions enveloppé dans InvocationTargetException et jetés à nouveau, etc.
4. Tout le traitement que Jon Skeet mentions ici .

Juste parce que quelque chose est 100x plus lent ne signifie pas qu'il est trop lent pour vous en supposant que la réflexion est la "bonne façon" pour vous de concevoir votre programme. Par exemple, j'imagine que les IDE font un usage intensif de la réflexion et que mon IDE est plutôt correct du point de vue des performances.

Après tout, le tête de réflexion est susceptible de être insignifiant quand par rapport à par exemple, l'analyse syntaxique de XML ou accès à une base de données !

Un autre point à retenir est que Les micro-benchmarks sont un mécanisme notoirement imparfait pour déterminer la rapidité d'un produit dans la pratique. . Ainsi que Tim Bender remarques la JVM prend du temps pour "chauffer", le JIT peut réoptimiser les points chauds du code à la volée, etc.

Answer 2

Votre test est peut-être défectueux. En général, la JVM peut optimiser l'instanciation normale mais ne peut pas faire d'optimisations pour le cas d'utilisation réfléchi. .

Pour ceux qui se demandent quels étaient les temps, j'ai ajouté une phase d'échauffement et utilisé un tableau pour maintenir les objets créés (plus similaire à ce qu'un vrai programme pourrait faire). J'ai exécuté le code de test sur mon système OSX, jdk7 et j'ai obtenu ceci :

L'instanciation de réflexion a pris:5180ms
L'installation normale a été faite : 2001ms

Test modifié :

public class Test {

    static class B {

    }

    public static long timeDiff(long old) {
        return System.nanoTime() - old;
    }

    public static void main(String args[]) throws Exception {

        int numTrials = 10000000;
        B[] bees = new B[numTrials];
        Class<B> c = B.class;
        for (int i = 0; i < numTrials; i++) {
            bees[i] = c.newInstance();
        }
        for (int i = 0; i < numTrials; i++) {
            bees[i] = new B();
        }

        long nanos;

        nanos = System.nanoTime();
        for (int i = 0; i < numTrials; i++) {
            bees[i] = c.newInstance();
        }
        System.out.println("Reflecting instantiation took:" + TimeUnit.NANOSECONDS.toMillis(timeDiff(nanos)) + "ms");

        nanos = System.nanoTime();
        for (int i = 0; i < numTrials; i++) {
            bees[i] = new B();
        }
        System.out.println("Normal instaniation took: " + TimeUnit.NANOSECONDS.toMillis(timeDiff(nanos)) + "ms");
    }

}

Answer 3

Le code JIT pour l'instanciation de B est le suivant incroyablement léger. En gros, il doit allouer suffisamment de mémoire (ce qui revient à incrémenter un pointeur à moins qu'un GC ne soit nécessaire) et c'est à peu près tout - il n'y a pas vraiment de code constructeur à appeler ; je ne sais pas si le JIT le saute ou non, mais dans tous les cas, il n'y a pas grand chose à faire.

Comparez cela avec tout ce que la réflexion doit faire :

• Vérifier qu'il y a un constructeur sans paramètre
• Vérifier l'accessibilité du constructeur sans paramètre
• Vérifier que l'appelant a le droit d'utiliser la réflexion.
• Déterminer (au moment de l'exécution) l'espace à allouer.
• Appel dans le code du constructeur (car il ne saura pas à l'avance que le constructeur est vide).

... et probablement d'autres choses auxquelles je n'ai pas encore pensé.

En général, la réflexion n'est pas utilisée dans un contexte de performances critiques ; si vous avez besoin d'un comportement dynamique de ce type, vous pouvez utiliser quelque chose comme BCEL à la place.

Answer 4

Il semble que si vous rendez le constructeur accessible, il s'exécutera beaucoup plus rapidement. Maintenant, il est seulement 10 à 20 fois plus lent que l'autre version.

    Constructor<B> c = B.class.getDeclaredConstructor();
    c.setAccessible(true);
    for (int i = 0; i < numTrials; i++) {
        c.newInstance();
    }

Normal instaniation took: 47ms
Reflecting instantiation took:718ms

Et si vous utilisez le Server VM, il est capable de l'optimiser davantage, de sorte qu'il n'est que 3 à 4 fois plus lent. C'est une performance tout à fait typique. L'article que Geo a lié est une bonne lecture.

Normal instaniation took: 47ms
Reflecting instantiation took:140ms

Mais si vous activez le remplacement scalaire avec -XX:+DoEscapeAnalysis, la JVM est capable d'optimiser l'instanciation régulière (0-15ms) mais l'instanciation réfléchie reste la même.

Answer 5

Peut-être que vous trouverez cet article intéressant.