Influence du paramétrage des collections sur les performances
Le
Jean-Baptiste LE DUIGOU
Depuis la version 5 de Java il est possible (et recommandé) de
paramétré les collections en spécifiant le type des instances qu'elle
va contenir.
Est-ce que ce paramétrage à des conséquence significative sur les
performances d'une application ?
Merci d'avance pour vos réponses.
paramétré les collections en spécifiant le type des instances qu'elle
va contenir.
Est-ce que ce paramétrage à des conséquence significative sur les
performances d'une application ?
Merci d'avance pour vos réponses.
Non. De manière générale, avec ou sans l'utilisation des génériques, le
bytecode généré est le même, donc pas de différence à l'exécution.
Les génériques sont un outil pour la phase de compilation, qui sert à
mieux assurer le typage des données. Et à éviter des millions de cast
explicites.
--
Mayeul
Oui cela aura une incidence. Quand a savoir si elle est significative...
L'utilisation des génériques permet au compilateur de vérifi er mieux le
typage du reste du programme, donc il évite des casts explicites, qui du
coup n'ont plus lieu à l'exécution.
Donc un programme avec des génériques sera au moins aussi efficac e que
le même programme sans génériques.
-- Alain.
Bonjour,
Il me semble qu'il y a une contradiction évidente entre ta réponse et
celle fournie par Mayeul...
En regardant ici
http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html
on peut lire, entre autre :
"Generics are implemented by type erasure: generic type information is
present only at compile time, after which it is erased by the compiler."
Donc si je comprends bien et que je n'ai pas raté de points importants
dans le reste du texte, on peut conclure que les génériques ne change
rien en ce qui concerne l'exécution.
devient donc : un programme sera tout aussi efficace (ou inefficace)
avec ou sans génériques :-)
--
Xavier Nayrac
http://personalbugtracker.free.fr
Tout à fait.
La raison étant, que les casts se font toujours quand on utilise les
génériques. Il est toujours nécessaire de vérifier qu'un objet est bien
de type attendu à l'exécution.
La différence, entre l'utilisation ou non des génériques, est que les
casts sont implicites avec les génériques : on n'a pas besoin de les
taper dans le code source.
--
Mayeul
Ah oui, tiens. Mon raisonnement était le suivant : comme c'est le
compilateur qui génère le code, et que lui sait qu'il n'y a pas l ieu de
vérifier, il pourrait éviter le cast. Dans la pratique ce n'est
effectivement pas le cas, le code est le même, qu'on utilise des
génériques ou pas (avec le jdk Sun du moins).
Je ne comprends pas pourquoi c'est nécessaire. J'ai l'impression qu'on
pourrait tranquillement virer des tas de checkcast.
Quelqu'un a une idée ?
-- Alain.
Ah ouais. Bon ben je suis très déçu, j'aurais préfà ©ré ne pas avoir de
compatibilité entre type raw et type générique, mais qu'au m oins on
gagne quelque chose au-delà du compilo.
-- Alain.
[...]
Ah ben voilà , je croyais que ça c'était interdit. Dommage qu e ça ne le
soit pas. Merci pour l'exemple.
-- Alain.
Oui, c'est une question de point de vue. Le reprise de l'existant est
certes importante, mais là les restrictions se propagent même lor squ'on
utilise exclusivement des génériques (il suffirait d'interdire
l'aliasing generic=raw, d'ailleurs, ce qui ne devrait pas impacter le
code existant -- qui n'utilise pas de generic). Et c'est peut-être
quelque millisecondes pour le checkcast, mais surtout ça risque de
rendre pénible des tas d'optimisations sur le bytecode (à cause de
l'éventuelle exception).
Attention, je ne suis pas contre les génériques, j'en voudrais m ême
beaucoup plus :-)
-- Alain.