Il parait que l'utilisation de reflect est à éviter à cause de la lenteur
...
Mais qu'est ce qui est lent et pourquoi ?
le getClass(), getMethod(), invoke() ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas Delsaux
Le 14.11 2003, s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Il parait que l'utilisation de reflect est à éviter à cause de la lenteur ... Mais qu'est ce qui est lent et pourquoi ?
C'est de moins en moins vrai, mais il était à un moment cent fois plus rapide d'appeler une méthode directement que d'utiliser l'introspection.
le getClass(), getMethod(), invoke() ?
Tous, mais surtout les deux derniers. je vais nuancer grandement mon propos : Dans la plupart des cas, utiliser l'introspection revient à jouer avec les mécanismes sous-jacents aux objets Java, et donc à "casser" la mécanique objet. En fait, il est générallement possible de s'en passer par l'utilisation d'interfaces et de ce que j'appelle des tables d'actions. Je vais être plus clair avec un exemple. Supposons que tu aies une classe A, dans laquelle tu as une méthode doA et une méthode doB, que tu appelles en fonction d'une chaîne de caractère contenant A ou B (je sais, c'est un exemple bidon). Il existe au moins trois possibilités pour appeler ces deux méthodes : 1 - écrire une série de if en fonction du contenu de la chaîne. C'est très moche, et surtout assez peu évolutif. Le code est donc : if("A") objet.doA() else if("B") objet.doB(); 2 - utiliser l'introspection pour générer le nom de la méthode, retrouver l'objet correspondant et appeler finallement cette méthode. Mis à part le fait que le code écrit sera redoutablement dangereux, il est en plus lent et lourd. Avec comme code : Class clazz = objet.getClass(); Method m = clazz.getMethod("do"+str); m.invoke(objet, null, null); 3 - écrire une interface doIt, ne contenant qu'une méthode do(), implémentée dans deux sous classes (doItA et doItB) qui appellent respectivement doA et doB. Tu associes dans une Map chaque chaîne à l'objet associé (ça peut même être fait dans un fichier de configuration, pour peu que les classes disposent de constructeurs simples), et ton code devient : récupération de l'interface associée à l'objet, et appel de la méthode, soit doIt actionner = myMap.get("A"); actionner.do(); C'est mieux, non ? Et plus évolutif.
En résumé, j'ai largement l'impression que l'utilisation de l'introspection révèle en général une faiblesse dans la conception d'un produit. Il faut donc l'utiliser avec plus que de la prudence.
-- Nicolas Delsaux "Une nymphomane est une femme aussi obsédée par le sexe que l'homme moyen." Mignon McLaughlin
Le 14.11 2003, s'est levé et s'est dit : "tiens, si j'écrivais aux mecs
de fr.comp.lang.java ?"
Il parait que l'utilisation de reflect est à éviter à cause de la
lenteur ...
Mais qu'est ce qui est lent et pourquoi ?
C'est de moins en moins vrai, mais il était à un moment cent fois plus
rapide d'appeler une méthode directement que d'utiliser l'introspection.
le getClass(), getMethod(), invoke() ?
Tous, mais surtout les deux derniers.
je vais nuancer grandement mon propos :
Dans la plupart des cas, utiliser l'introspection revient à jouer avec
les mécanismes sous-jacents aux objets Java, et donc à "casser" la
mécanique objet. En fait, il est générallement possible de s'en passer
par l'utilisation d'interfaces et de ce que j'appelle des tables
d'actions. Je vais être plus clair avec un exemple. Supposons que tu
aies une classe A, dans laquelle tu as une méthode doA et une méthode
doB, que tu appelles en fonction d'une chaîne de caractère contenant A
ou B (je sais, c'est un exemple bidon). Il existe au moins trois
possibilités pour appeler ces deux méthodes :
1 - écrire une série de if en fonction du contenu de la chaîne. C'est
très moche, et surtout assez peu évolutif. Le code est donc :
if("A") objet.doA()
else if("B") objet.doB();
2 - utiliser l'introspection pour générer le nom de la méthode,
retrouver l'objet correspondant et appeler finallement cette méthode.
Mis à part le fait que le code écrit sera redoutablement dangereux, il
est en plus lent et lourd. Avec comme code :
Class clazz = objet.getClass();
Method m = clazz.getMethod("do"+str);
m.invoke(objet, null, null);
3 - écrire une interface doIt, ne contenant qu'une méthode do(),
implémentée dans deux sous classes (doItA et doItB) qui appellent
respectivement doA et doB. Tu associes dans une Map chaque chaîne à
l'objet associé (ça peut même être fait dans un fichier de
configuration, pour peu que les classes disposent de constructeurs
simples), et ton code devient : récupération de l'interface associée à
l'objet, et appel de la méthode, soit
doIt actionner = myMap.get("A");
actionner.do();
C'est mieux, non ?
Et plus évolutif.
En résumé, j'ai largement l'impression que l'utilisation de
l'introspection révèle en général une faiblesse dans la conception d'un
produit. Il faut donc l'utiliser avec plus que de la prudence.
--
Nicolas Delsaux
"Une nymphomane est une femme aussi obsédée par le sexe que l'homme
moyen." Mignon McLaughlin
Le 14.11 2003, s'est levé et s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java ?"
Il parait que l'utilisation de reflect est à éviter à cause de la lenteur ... Mais qu'est ce qui est lent et pourquoi ?
C'est de moins en moins vrai, mais il était à un moment cent fois plus rapide d'appeler une méthode directement que d'utiliser l'introspection.
le getClass(), getMethod(), invoke() ?
Tous, mais surtout les deux derniers. je vais nuancer grandement mon propos : Dans la plupart des cas, utiliser l'introspection revient à jouer avec les mécanismes sous-jacents aux objets Java, et donc à "casser" la mécanique objet. En fait, il est générallement possible de s'en passer par l'utilisation d'interfaces et de ce que j'appelle des tables d'actions. Je vais être plus clair avec un exemple. Supposons que tu aies une classe A, dans laquelle tu as une méthode doA et une méthode doB, que tu appelles en fonction d'une chaîne de caractère contenant A ou B (je sais, c'est un exemple bidon). Il existe au moins trois possibilités pour appeler ces deux méthodes : 1 - écrire une série de if en fonction du contenu de la chaîne. C'est très moche, et surtout assez peu évolutif. Le code est donc : if("A") objet.doA() else if("B") objet.doB(); 2 - utiliser l'introspection pour générer le nom de la méthode, retrouver l'objet correspondant et appeler finallement cette méthode. Mis à part le fait que le code écrit sera redoutablement dangereux, il est en plus lent et lourd. Avec comme code : Class clazz = objet.getClass(); Method m = clazz.getMethod("do"+str); m.invoke(objet, null, null); 3 - écrire une interface doIt, ne contenant qu'une méthode do(), implémentée dans deux sous classes (doItA et doItB) qui appellent respectivement doA et doB. Tu associes dans une Map chaque chaîne à l'objet associé (ça peut même être fait dans un fichier de configuration, pour peu que les classes disposent de constructeurs simples), et ton code devient : récupération de l'interface associée à l'objet, et appel de la méthode, soit doIt actionner = myMap.get("A"); actionner.do(); C'est mieux, non ? Et plus évolutif.
En résumé, j'ai largement l'impression que l'utilisation de l'introspection révèle en général une faiblesse dans la conception d'un produit. Il faut donc l'utiliser avec plus que de la prudence.
-- Nicolas Delsaux "Une nymphomane est une femme aussi obsédée par le sexe que l'homme moyen." Mignon McLaughlin
Dans la plupart des cas, utiliser l'introspection revient à jouer avec les mécanismes sous-jacents aux objets Java, et donc à "casser" la mécanique objet.
bé c'est là que je pige pas : la redefinition c'est bien quand il y a un changement de comportement mais c'est l'envers que je veux faire avec reflect. quand xmlEncoder sérialize un bean en xml par exemple, il invoke tous les selecteurs pour récupérer les valeurs (c'est un truc du genre que je fais) xml propose d'accéder à un élément sans le nommer (sibling...) = c'est le progrès et çà choque personne ...
_j'imagine que getClass prenne du temps : lecture du fichier .class. _getMethod = recherche de signature = une petite boucle avec un break = pas trop long ... _invoke : appel de la méthode avec passage des arguments selon la signature : donc fonction du nombre de paramètres = pas trop long
toujours pas convaincu ... -- François LE DORNER.
Dans la plupart des cas, utiliser l'introspection revient à jouer avec
les mécanismes sous-jacents aux objets Java, et donc à "casser" la
mécanique objet.
bé c'est là que je pige pas :
la redefinition c'est bien quand il y a un changement de comportement mais
c'est l'envers que je veux faire avec reflect.
quand xmlEncoder sérialize un bean en xml par exemple, il invoke tous les
selecteurs pour récupérer les valeurs (c'est un truc du genre que je fais)
xml propose d'accéder à un élément sans le nommer (sibling...) = c'est le
progrès et çà choque personne ...
_j'imagine que getClass prenne du temps : lecture du fichier .class.
_getMethod = recherche de signature = une petite boucle avec un break = pas
trop long ...
_invoke : appel de la méthode avec passage des arguments selon la signature
: donc fonction du nombre de paramètres = pas trop long
Dans la plupart des cas, utiliser l'introspection revient à jouer avec les mécanismes sous-jacents aux objets Java, et donc à "casser" la mécanique objet.
bé c'est là que je pige pas : la redefinition c'est bien quand il y a un changement de comportement mais c'est l'envers que je veux faire avec reflect. quand xmlEncoder sérialize un bean en xml par exemple, il invoke tous les selecteurs pour récupérer les valeurs (c'est un truc du genre que je fais) xml propose d'accéder à un élément sans le nommer (sibling...) = c'est le progrès et çà choque personne ...
_j'imagine que getClass prenne du temps : lecture du fichier .class. _getMethod = recherche de signature = une petite boucle avec un break = pas trop long ... _invoke : appel de la méthode avec passage des arguments selon la signature : donc fonction du nombre de paramètres = pas trop long
toujours pas convaincu ... -- François LE DORNER.
dominique.dechamps
D'aprés mes essais (voir http://dominique.dechamps.free.fr/JA/html/BenchMark/JABenchMark.htm) invoke coute de 11 à 40 fois un appel en dur à une méthode. Mais tout ceci n'est que relatif ... L'utilisation de la reflexivité du code peut sembler pour notre époque fort couteux en terme de perf ...mais qu'auraient dit les "vieux" programmeurs système de la POO, de la JVM, de la conso mémoire ... Ce qui compte c'est surtout la création de techniques novatrices qui s'appuient sur la reflexivité comme l'AOP. Le hardware suivra (ou précedera c'est selon)
D'aprés mes essais (voir
http://dominique.dechamps.free.fr/JA/html/BenchMark/JABenchMark.htm)
invoke coute de 11 à 40 fois un appel en dur à une méthode.
Mais tout ceci n'est que relatif ...
L'utilisation de la reflexivité du code peut sembler pour notre époque
fort couteux en terme de perf ...mais qu'auraient dit les "vieux"
programmeurs système de la POO, de la JVM, de la conso mémoire ... Ce
qui compte c'est surtout la création de techniques novatrices qui
s'appuient sur la reflexivité comme l'AOP. Le hardware suivra (ou
précedera c'est selon)
D'aprés mes essais (voir http://dominique.dechamps.free.fr/JA/html/BenchMark/JABenchMark.htm) invoke coute de 11 à 40 fois un appel en dur à une méthode. Mais tout ceci n'est que relatif ... L'utilisation de la reflexivité du code peut sembler pour notre époque fort couteux en terme de perf ...mais qu'auraient dit les "vieux" programmeurs système de la POO, de la JVM, de la conso mémoire ... Ce qui compte c'est surtout la création de techniques novatrices qui s'appuient sur la reflexivité comme l'AOP. Le hardware suivra (ou précedera c'est selon)
dominique.dechamps
Une remarque sur
En résumé, j'ai largement l'impression que l'utilisation de l'introspection révèle en général une faiblesse dans la conception d'un produit. Il faut donc l'utiliser avec plus que de la prudence. C'est vrai si en en tant que développeur tu peux avoir une
connaissance a-priori de toutes les classes et de leurs méthodes mais les développeurs d'outils de "manipulation" de code eux ont besoin de l'introspection/reflexivité de code car ils ne savent pas a-priori (au moment du codage) quelles méthodes de quelles classes leurs outils auront à s'occuper (je pense en particulier au tissage de codes en Programmation Orientée Aspects) ... Peut-être faiblesse dans un cas, mais absolue nécessité dans un autre. Aprés on peut toujours discuter du besoin, de l'intêret de tels outils.
Une remarque sur
En résumé, j'ai largement l'impression que l'utilisation de
l'introspection révèle en général une faiblesse dans la conception d'un
produit. Il faut donc l'utiliser avec plus que de la prudence.
C'est vrai si en en tant que développeur tu peux avoir une
connaissance a-priori de toutes les classes et de leurs méthodes mais
les développeurs d'outils de "manipulation" de code eux ont besoin de
l'introspection/reflexivité de code car ils ne savent pas a-priori (au
moment du codage) quelles méthodes de quelles classes leurs outils
auront à s'occuper (je pense en particulier au tissage de codes en
Programmation Orientée Aspects) ... Peut-être faiblesse dans un cas,
mais absolue nécessité dans un autre. Aprés on peut toujours discuter
du besoin, de l'intêret de tels outils.
En résumé, j'ai largement l'impression que l'utilisation de l'introspection révèle en général une faiblesse dans la conception d'un produit. Il faut donc l'utiliser avec plus que de la prudence. C'est vrai si en en tant que développeur tu peux avoir une
connaissance a-priori de toutes les classes et de leurs méthodes mais les développeurs d'outils de "manipulation" de code eux ont besoin de l'introspection/reflexivité de code car ils ne savent pas a-priori (au moment du codage) quelles méthodes de quelles classes leurs outils auront à s'occuper (je pense en particulier au tissage de codes en Programmation Orientée Aspects) ... Peut-être faiblesse dans un cas, mais absolue nécessité dans un autre. Aprés on peut toujours discuter du besoin, de l'intêret de tels outils.
