Bonjour, j'ai entendu dire que tout ce qui est Vector, Hashtable, et
autres collection, ainsi que ce que propose le projet Trove allaient
être obsoletes du fait de nouvelles optimisations de compilation de JDK
1.5.0 sur la gestion des primitives dans les structures de données... je
n'arrive pas à trouver de lien sur cela...
quelqu'un peut il confirmer et m'indiquer une page pour en savoir plus ?
Bonjour, j'ai entendu dire que tout ce qui est Vector, Hashtable, et autres collection, ainsi que ce que propose le projet Trove allaient être obsoletes du fait de nouvelles optimisations de compilation de JDK 1.5.0 sur la gestion des primitives dans les structures de données... je n'arrive pas à trouver de lien sur cela... quelqu'un peut il confirmer et m'indiquer une page pour en savoir plus ?
Bonjour, j'ai entendu dire que tout ce qui est Vector, Hashtable, et
autres collection, ainsi que ce que propose le projet Trove allaient
être obsoletes du fait de nouvelles optimisations de compilation de JDK
1.5.0 sur la gestion des primitives dans les structures de données... je
n'arrive pas à trouver de lien sur cela...
quelqu'un peut il confirmer et m'indiquer une page pour en savoir plus ?
Bonjour, j'ai entendu dire que tout ce qui est Vector, Hashtable, et autres collection, ainsi que ce que propose le projet Trove allaient être obsoletes du fait de nouvelles optimisations de compilation de JDK 1.5.0 sur la gestion des primitives dans les structures de données... je n'arrive pas à trouver de lien sur cela... quelqu'un peut il confirmer et m'indiquer une page pour en savoir plus ?
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser
des types primitifs dans les collections, mais que derrière le
compilateur instantie quand même les classes de wrapper et que donc ce
serait un gros piège car il n'y aurait aucune optimisation des
performances sur les types primitifs, ca reste a confirmer
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
c'est mon avis aussi, et un piege de plus pour la une, un !!!!
Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser
des types primitifs dans les collections, mais que derrière le
compilateur instantie quand même les classes de wrapper et que donc ce
serait un gros piège car il n'y aurait aucune optimisation des
performances sur les types primitifs, ca reste a confirmer
c'est mon avis aussi, et un piege de plus pour la une, un !!!!
Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
c'est mon avis aussi, et un piege de plus pour la une, un !!!!
Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser
des types primitifs dans les collections, mais que derrière le
compilateur instantie quand même les classes de wrapper et que donc ce
serait un gros piège car il n'y aurait aucune optimisation des
performances sur les types primitifs, ca reste a confirmer
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed,
donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui
s'imposent et creera un bug chez Sun.
Oui mais je crois que l'autoboxing n'est qu'une facilité pour utiliser des types primitifs dans les collections, mais que derrière le compilateur instantie quand même les classes de wrapper et que donc ce serait un gros piège car il n'y aurait aucune optimisation des performances sur les types primitifs, ca reste a confirmer
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
Pif
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les
mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que
mon appli a besoin de types primitifs pour gagner en performance, sinon,
ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Farid
Un de mes collegues a ecrit ce truc, qui marche tres bien, et est gratuit.
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Un de mes collegues a ecrit ce truc, qui marche tres bien, et est gratuit.
"Pif" <pif@ifrance.com> wrote in message news:c4juat$3ve$1@eerie.ema.fr...
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les
mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que
mon appli a besoin de types primitifs pour gagner en performance, sinon,
ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Pif
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai catastrophe faisant planter la JVM fréquemment sur des masses de données importantes... je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à 200 000² ... il me fait quelquechose de vraiment efficace !
mais c'est l'occasion de tester...
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test
sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai
catastrophe faisant planter la JVM fréquemment sur des masses de données
importantes...
je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à
200 000² ... il me fait quelquechose de vraiment efficace !
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai catastrophe faisant planter la JVM fréquemment sur des masses de données importantes... je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à 200 000² ... il me fait quelquechose de vraiment efficace !
mais c'est l'occasion de tester...
Marc Collin
Pif wrote:
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai catastrophe faisant planter la JVM fréquemment sur des masses de données importantes... je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à 200 000² ... il me fait quelquechose de vraiment efficace !
mais c'est l'occasion de tester... ça serait bien si tu pourrais nous donner le résultat de tes test...
-- Borland rulez http://pages.infinit.net/borland
Pif wrote:
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test
sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai
catastrophe faisant planter la JVM fréquemment sur des masses de données
importantes...
je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à
200 000² ... il me fait quelquechose de vraiment efficace !
mais c'est l'occasion de tester...
ça serait bien si tu pourrais nous donner le résultat de tes test...
intéressant, mais ce que je regrette, c'est qu'il n'y ait pas de test sur la mémoire, s'aspect dynamique et le GC qui peuvent devenir de vrai catastrophe faisant planter la JVM fréquemment sur des masses de données importantes... je dois actuellement gerer une masse de donnée de l'ordre de 10 000² à 200 000² ... il me fait quelquechose de vraiment efficace !
mais c'est l'occasion de tester... ça serait bien si tu pourrais nous donner le résultat de tes test...
-- Borland rulez http://pages.infinit.net/borland
Örjan Petersson
Pif writes:
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire
disparaître la différence entre les types primitifs (int, short, ...) et les références correspondants (Integer, Short, ...), et Hotspot ne peut pas faire disparaître cette différence. Par exemple, une List<Integer> (nouvelle syntaxe pour la généricité) restera une liste de "Integer" (et non pas de "int") et il y a toujours de conversions Integer<->int dans
List<Integer> li = new ArrayList<Integer>(); Integer i = 378; // autoboxing int -> Integer li.add(i); li.add(556); // autoboxing int -> Integer int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>(); Integer i = Integer.valueOf(378); // ou new Integer(378) li.add(i); li.add(Integer.valueOf(556)); int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Donc, si tu as besoin de types primitifs pour de raisons de performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing", etc.? -- Orjan Petersson, Logcode SARL The email address in the From: header is valid
Pif <pif@ifrance.com> writes:
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera
les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est
que mon appli a besoin de types primitifs pour gagner en performance,
sinon, ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire
disparaître la différence entre les types primitifs (int, short, ...)
et les références correspondants (Integer, Short, ...), et Hotspot ne
peut pas faire disparaître cette différence. Par exemple, une
List<Integer> (nouvelle syntaxe pour la généricité) restera une liste
de "Integer" (et non pas de "int") et il y a toujours de conversions
Integer<->int dans
List<Integer> li = new ArrayList<Integer>();
Integer i = 378; // autoboxing int -> Integer
li.add(i);
li.add(556); // autoboxing int -> Integer
int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>();
Integer i = Integer.valueOf(378); // ou new Integer(378)
li.add(i);
li.add(Integer.valueOf(556));
int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Donc, si tu as besoin de types primitifs pour de raisons de
performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing",
etc.?
--
Orjan Petersson, Logcode SARL
The email address in the From: header is valid
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire
disparaître la différence entre les types primitifs (int, short, ...) et les références correspondants (Integer, Short, ...), et Hotspot ne peut pas faire disparaître cette différence. Par exemple, une List<Integer> (nouvelle syntaxe pour la généricité) restera une liste de "Integer" (et non pas de "int") et il y a toujours de conversions Integer<->int dans
List<Integer> li = new ArrayList<Integer>(); Integer i = 378; // autoboxing int -> Integer li.add(i); li.add(556); // autoboxing int -> Integer int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>(); Integer i = Integer.valueOf(378); // ou new Integer(378) li.add(i); li.add(Integer.valueOf(556)); int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Donc, si tu as besoin de types primitifs pour de raisons de performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing", etc.? -- Orjan Petersson, Logcode SARL The email address in the From: header is valid
Marc Petit-Huguenin
Örjan Petersson wrote:
Pif writes:
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire disparaître la différence entre les types primitifs (int, short, ...) et les références correspondants (Integer, Short, ...), et Hotspot ne peut pas faire disparaître cette différence.
Je ne suis pas d'accord. Pourquoi est-ce que Hotspot ne pourrait pas transformer un Integer[] en int[] dans le code natif genere? "Ne pas utiliser x, parceque x a des problemes de performance" est l'un des pire conseil que l'on puisse donner.
Par exemple, une List<Integer> (nouvelle syntaxe pour la généricité) restera une liste de "Integer" (et non pas de "int") et il y a toujours de conversions Integer<->int dans
List<Integer> li = new ArrayList<Integer>(); Integer i = 378; // autoboxing int -> Integer li.add(i); li.add(556); // autoboxing int -> Integer int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>(); Integer i = Integer.valueOf(378); // ou new Integer(378) li.add(i); li.add(Integer.valueOf(556)); int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Exactement. Mais ce n'est pas le probleme. Le probleme est, qu'est-ce que Hotspot fait avec ces bytecodes?
Donc, si tu as besoin de types primitifs pour de raisons de performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing", etc.?
Je propose "boxing" pour boxing, et "unboxing" pour unboxing.
Örjan Petersson wrote:
Pif <pif@ifrance.com> writes:
IMO: Hotspot peut (va?) optimiser les collections de primitives
auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera
les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est
que mon appli a besoin de types primitifs pour gagner en performance,
sinon, ca ferait trop d'objets qui feraient exploiser mister GC !
Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ?
(nb, quelqu'un connait quelque chose de mieux que trove pour faire des
hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire
disparaître la différence entre les types primitifs (int, short, ...)
et les références correspondants (Integer, Short, ...), et Hotspot ne
peut pas faire disparaître cette différence.
Je ne suis pas d'accord. Pourquoi est-ce que Hotspot ne pourrait pas
transformer un Integer[] en int[] dans le code natif genere?
"Ne pas utiliser x, parceque x a des problemes de performance" est l'un des
pire conseil que l'on puisse donner.
Par exemple, une
List<Integer> (nouvelle syntaxe pour la généricité) restera une liste
de "Integer" (et non pas de "int") et il y a toujours de conversions
Integer<->int dans
List<Integer> li = new ArrayList<Integer>();
Integer i = 378; // autoboxing int -> Integer
li.add(i);
li.add(556); // autoboxing int -> Integer
int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>();
Integer i = Integer.valueOf(378); // ou new Integer(378)
li.add(i);
li.add(Integer.valueOf(556));
int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Exactement. Mais ce n'est pas le probleme. Le probleme est, qu'est-ce que
Hotspot fait avec ces bytecodes?
Donc, si tu as besoin de types primitifs pour de raisons de
performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing",
etc.?
Je propose "boxing" pour boxing, et "unboxing" pour unboxing.
IMO: Hotspot peut (va?) optimiser les collections de primitives auto-boxed, donc pourquoi se faire du soucis? Au pire quelqu'un fera les mesures qui s'imposent et creera un bug chez Sun.
sans parler de bug, si c'est uniquement syntaxique, le problème est que mon appli a besoin de types primitifs pour gagner en performance, sinon, ca ferait trop d'objets qui feraient exploiser mister GC ! Donc la question, c'est est-ce exploitable ou dois-je en rester à Trove ? (nb, quelqu'un connait quelque chose de mieux que trove pour faire des hashtable de int ou de floats ?)
Le but de "autoboxing/autounboxing" n'est pas de complètement faire disparaître la différence entre les types primitifs (int, short, ...) et les références correspondants (Integer, Short, ...), et Hotspot ne peut pas faire disparaître cette différence.
Je ne suis pas d'accord. Pourquoi est-ce que Hotspot ne pourrait pas transformer un Integer[] en int[] dans le code natif genere? "Ne pas utiliser x, parceque x a des problemes de performance" est l'un des pire conseil que l'on puisse donner.
Par exemple, une List<Integer> (nouvelle syntaxe pour la généricité) restera une liste de "Integer" (et non pas de "int") et il y a toujours de conversions Integer<->int dans
List<Integer> li = new ArrayList<Integer>(); Integer i = 378; // autoboxing int -> Integer li.add(i); li.add(556); // autoboxing int -> Integer int j = li.get(0); // unboxing Integer -> int
C'est plus lisible que
List<Integer> li = new ArrayList<Integer>(); Integer i = Integer.valueOf(378); // ou new Integer(378) li.add(i); li.add(Integer.valueOf(556)); int i = li.get(0).intValue();
mais, au fond, c'est le même bytecode.
Exactement. Mais ce n'est pas le probleme. Le probleme est, qu'est-ce que Hotspot fait avec ces bytecodes?
Donc, si tu as besoin de types primitifs pour de raisons de performance ce n'est pas 1.5 qui changera grande chose.
Question annexe : quelle terme français utiliser pour "boxing", "unboxing", etc.?
Je propose "boxing" pour boxing, et "unboxing" pour unboxing.
