Reprise du message précédent :

 
bon, ben j'ai lu le lien, et il dit que c'est spécifique au 1.4
 
donc quand tu hurles, dis bien dans quel cadre tu le fais
 
PUTAIN, IL MANQUE QUE C'EST DEPUIS LE 1.4
 

Je viens d'utiliser, encore une autre fois, une hashtable.
Conclusion : j'ai explosé le tas dans le programme
A chaque itération, j'affiche la taille de ma table de hash (plus précisément, le nombre d'éléments qu'elle stocke), voilà la valeur des  3 dernières itérations :

 
msg d'erreur à la prochaine itération :

 
Je suis assez étonné de la petite taille du tas . Cela vous paraît-t-il normal ? Je veux dire vous vous dîtes "oui, effectivement pour une table de hash, cela représente beaucoup d'éléments" ou bien "non, c'est ton prog qui alloue trop de mémoire en plus de la table de hash" ?  

oui ca fait beaucoup pour une table de hashage.
mais sic'est normal que tu en ais autant, tu as qu'à augmenter la taille allouée à ta JVM : java -Xmx128m par exemple

 
OK. Mais cela craint, après il faut dire à l'utilisateur de paramétrer sa JVM pour exécuter l'appli    
Je pense plutôt borner le nombre d'éléments dans ma table de hash.

Je viens de voir, je genere au tout début à l'initialisation de mon algo un tableau de 300 000 case, chacune pointant sur un tableau de 53 cases chacune contenant un int.
En taille mémoire cela répresente environ 60Mo.
Avec les réglages par défaut, la JVM me balance un "NoSuchMemoryError" malgré mes 512 Mo de ram

elle existe pas cette exception ...
et comme je te l'ai déjà dit, la jvm n'utilise pas toute la mémoire du PC si tu ne lui dis pas. Par défaut c'est 32Mo ou 64Mo max je crois ...
 
et c'est quoi ton prog là ?? tu simules l'univers ?

 
je voulais dire :

 

 
Sinon, euh, ouai presque  

 
 
bonjour, la barrette de ram que vous avez demandée n'est pas disponible pour l'instant, veuillez s'il vous plait repasser plus tard, quand on aura terminé de ripper le dvd

Explication tres efficace benou j'adore

En fait je crois avoir fait le GROS boulet    
En fait ma table de hash contient pour clé (qui est égale à la valeur aussi) un tableau de 100 int environ.
Donc avec quasi 100 000 entrées, ça commence à vite saturer.
Une solution nettement moins débile serait de convertir en String le tableau de 100 int et de récupérer le hashCode de cette String. Ainsi la table de hash aurait pour clé/valeur ce hashCode dépendant directement de la String et donc indirectement du tableau de 100 int.
Ainsi, la table de hash stockerait plus qu'un seul int (le hashCode) au lieu des 100 int pour chaque entrée.
Il en découle deux questions :
 
1) A partir de X String différentes, est-on SUR d'avoir X hashCode différents ? (je pense que oui, mais je n'ai pas le code source sous les yeux )  
 
2) Si oui pour la question 1, alors à quoi sert de stocker des Object dans une hashtable alors qu'il suffirait juste de les convertir en String puis récupérer le hashCode. De plus, dans ce cas, il ne serait plus nécessaire de définir les méthodes "public int hashCode ()" et "boolean equals (Object o)" car le hashCode d'un Integer (qui serait égal à "new Integer (hashCode)" ) est automatique : java prends directement la intValue () comme clé.
 
Merci de vos réponses  

non. Que la clef soit un tableau ou n'importe quel autre objet, la map ne va sauvegarder qu'un seul int pour le hashcode. Pourquoi ce serait autrement ?
 
Mais utiliser un tableau comme clef pour une table de hashage me parait assez habérant ... d'ailleur, je me demande comment le hascode  est calculé sur un tableau . Si je devais parrier je dirais que c'est l'implémentation de Object.
 
Elle te sert à quoi ta table de hashage ?
 

ben non. réfléchis 2 sec ... si c'était le cas, ca voudrait dire qu'il ne peux exister que 2^32 chaines de caractères (puisqu'un int peut prendre 2^32 valeurs). Ce qui est bien évidement faux.
 
Si t'as pas compris ca, t'as pas du comprendre le fonctionnement de l'algo de hachage
 

quelle idée    
 
Tu crois vraiment que n'importe quel objet peut se transformer en String ? allez, juste un exemple : l'objet Univers, tu le représentes comment avec une String ?
Et même si c'était le cas, tu penses vraiment que ce serait performant de devoir convertir l'objet en String ?
 
C'est vraiment une drôle d'idée ...

 
Je ne suis pas d'accord avec toi : en fait, au départ, ma clé/valeur (je passe la même référence) est une instance de la classe SubSet.
Cette classe contient comme membre privé, une référence sur un tableau de int[]. Une instance de cette classe est utilisé comme clé/valeur de la table de hash (pour les put () et get () entre autres). Pour créer une  instance de cette classe SubSet, je dois lui fournir le tableau de référence (celui de 100 int). L'instance de la classe SubSet étant utlisée comme clé/valeur, je dois y définir les méthodes equals () et hashCode () donc. Or ces 2 méthodes, par exemple equals (), utilisent le tableau de 100 int (logique, equals () ne fait que comparer si c'est les memes). Conclusion : pour chaque instance, celle ci est présente dans la table de hash et par conséquent il existera toujours une référence qui pointera sur ce tableau de 100 int; il ne peut donc pas etre supprimé de la mémoire...d'ou la necessité de convertir en String le tableau et de prendre le hashCode de la String comme clé/valeur
 

 
Il est vrai que ta remarque est tout a fait logique, je n'y avais pas pensé   Ceci dit, j'aimerais bien connaître la proba que 2 String (de 100 caracteres dans mons cas) différentes fournissent le même hashCode   Je pense qu'elle est très faible (peut être peut-on se contenter de cette approximation , cela dépend du programme)
 

 
Il est vrai que comme ma question 1) dans l'absolu est fausse, la question 2 n'a pas lieu d'être    
Pour la performance, des moments il faut faire des choix : ou bien ton objet est referencé par la table de hash, auquel cas il sera toujours en mémoire (gain en temps et perte en mémoire car a la base ton Objet est la plupart du temps constitué de plusieurs variable de type primitif (int, double,etc...)), ou bien tu convertis ton objet en String, ce qui peut prendre du temps, et tu generes le hashCode de celle ci et ainsi ta table de hash ne retiendrait qu'un int (gain memoire, perte en temps). Pour le 2ème cas, comme tu l'as dit, dans l'absolu le hashCode peut etre le meme pour 2 String différentes. Maintenant, il m'interesserait de connaitre la proba que ce hashCode soit le meme.

bon ...
 
1) tu avais di que c'était un tableau de int qui était utilisé comme clef&valeur. Maintenant tu me dis que c'est un objet qui contient le tableau ... ca fait déjà une grosse différence ...
 
2) je compend rien à ton histoire de de "être supprimé de la mémoire" ou "nécessité de convertir en String" .  
 
3) Pour ton histoire de perf le fait de le transformer en String ne serts absolument à rien. Dans les cas où un hashCode est long à calculer, il suffit de faire du cache : la première fois tu le calcul et tu sauve sa valeur, et les fois suivantes tu retourne la valeur déjà calculée. C'est d'ailleur ce qui est fait dans l'objet String si tu regardes son code source.
 
4) pour ton histoire de proba, on s'en fout : D'abord parce que l'algo a certainement été choisit justement pour que cette proba soit faible. Et ensuite parce que c'est pas parce que pour 2 objets différents on a le même hashcode que c'est un problême ! D'autant plus que d'ans l'algorythme de hachage, le hasCode est toujours modulé => les hashCode modulés sont très souvent égaux pour des objets différents

 
en fait ça ressemble à ça :
 

 
puis le petit main qui va bien avec :

 
alors dans le cas ci-dessus, c'est bien une référence (ici subSet) qui contient pointe sur un objet SubSet et donc indirectement sur le tableau. Donc que je prenne pour clé/valeur la variable "subSet" ou bien directement la variable "tableau" (dans le main()), je ne pense pas que ca change grand chose. Schématiquement ce serait :
 
- Dans le cas où le tableau est contenu par l'objet subSet :
 
subSet->tableau->int[];
 
- Dans le cas où le tableau est contenu par rien du tout, si n'est seulement par la référence sur le tableau :
 
tableau->int[];
 
Les flèches sont à traduire par "pointe sur". Dans ce shéma, on voit bien que si je hash "subSet" ou bien "tableau", ça change pas grand chose : dans les 2 cas mon tableau de int[] reste en mémoire.
 
 

 
Ben le garbage collector supprime un objet de la mémoire à partir du moment où il est sûr que l'objet ne pourra pas être utilisé. Autrement dit, si je garde toujours une référence sur mon tableau de 100 int (variable "tableau" de la classe SubSet qui pointe dessus) il est certain que l'objet ne sera jamais détruit (= supprimé de la mémoire).
Donc si je mets 100 clés dans ma table de hash je mets donc indirectement 100 tableaux de 100 int ce qui commence vite a saturer la mémoire.
Par conséquent, si je convertis en String le tableau de 100 int, ensuite je récupère le hashCode de cette String, je prendrai pour clé/valeur le hashCode de cette String qui dépend indirectement de mon tableau de 100 int. Donc si a partir de la je mets 100 clés dans ma table de hash, je mets donc indirectement 100 int (100 hashCode de String) ce qui est nettement moins gourmand en mémoire.
Par contre dans ce cas le problème est de toujours convertir le tableau de 100 int en String avant d'insérer dans la table de hash (perte de temps).
 

 
Ton système de cache est pas bête du tout.   Mais dans mon cas je n'ai qu'un tableau de 100 int, je ne peux rien mettre en cache
 

 
Ben moi je ne m'en fou pas tant que ça car si j'ai 2 String différentes et donc que j'ai indirectement 2 tableaux de 100 int différents; admettons que j'ai le même hashCode de ces 2 String :
lorsque je fais le code suivant :

 
J'espère avoir été plus clair  

C'est n'importe quoi ta méthode hashcode ! T'as déjà vu à quoi ca ressemblait le toString d'un tableau de int ?
avec l'implémentation que tu as faite, la règle liant equals et hashcode n'est pas respectée => ca va donner n'importe quoi ta Map.
 

ben si ca change tout puisque equals et hascode ne sont pas calculés de la même façon
 

bha bien sur qu'il reste en mémore. Où tu voudrais qu'il aille ?    
 

mais
 
De quoi tu parles là ??? En quoi calculer le hashcode à partir d'une version String de ton tableau va te faire économiser de la mémoire ? De toute façon ton tableau sera toujours dans la map au final donc tu ne gagne rien ! Je vois vraiment pas où tu veux en venir ...
En plus, pkoi ta String prendrait moins de place que le tableau de int qu'elle représente. Ca risque d'être vrai pour les petits entiers, mais dès qu'ils sertont plus grand ca le sera plus du tout, au contraire !
 

ben si : le hachcode que tu aura calculé à partir de ton tableau de int. Mai sà mon avis, t'as rien compris à ce qu'était le hashcode ...
 

oui t'as été clair : t'as rien compris au fonctionnement de l'algo de hashage. relis le début du thread, j'explique comment ca marche.

 

 
Pour ma méthode toString, par exemple pour le tableau 01234, ca me renvoie simplement la chaîne "01234" c'est tout.
Pour la règle liant equals et hashCode, je me suis complètement déchiré  . C'est un mélange de mon vieux code et du nouveau   . Bref, oublie la class SubSet finalement .
Je calcule donc juste, avant de regarder dans la table de hash, le hashCode du tableau de 100 int via la méthode toString ().
 

 
Bon, on va oublié la class SubSet, c'était une connerie
 
 

 
En fait, mes tableaux de 100 int sont générés aléatoirement (bon je simplifie c'est un peu plus subtile). Je convertis juste ca en String, calcule le hashCode, regarde s'il est le même (même si dans l'absolu ca peut etre 2 String différentes). Si ce hashCode est deja dans la table, je considère que ce tableau de 100 int est présent (auquel cas je ne vais pas plus loin dans l'algo). S'il n'est pas présent, j'ajoute le hashCode dans la table de hash (en faisant une ou 2 instructions en plus)
 

 
Comme mes tableaux sont générés "aléatoirement", je ne peux rien mettre en cache car j'ai un ENORME nombre de permutations possible (100! pour un tableau de 100 int).
 

 
Ben en fait, j'ai bien compris, c'est juste que je ne m'été pas relus   . Effectivement la class SubSet était débile. En fait comme je n'utilise plus qu'un int (le hashCode de la String comme clé/valeur),
je fais :
table_de_hash.put (new integer (hashCode)).
Voilà, et là, la méthode equals est bonne

je laisse tomber ...
 
et j'ai moi :

ca donne

 
ma méthode toString est toute conne : en gros :
 

c'est pas le code que t'as donné tout à l'heure ...
 
mais même : construire une chaine juste pour pas se faire un hashage soi même c'est nul ...

 
Ben la méthode toString (), je ne l'avais jamais donnée    
Sinon ben pour le hashCode, je vois pas ce que je peux prendre d'autre pour un tableau de 100 int   ... sachant que mes tableaux sont TOUS identiques à part l'emplacement des entiers qui diffèrent. Si tu vois autre chose, mais je doute...
par exemple 2 tableaux différents : 1234 et 4231 => seuls les emplacements des int diffèrent.

jcrois qu il est temps de laché l'affaire la

 
ben si tu as une autre solution je suis preneur  

exemple :  
int sum = 0;
for (int i=0; i < tab.length; i++) {
   sum = sum * 23 + tab[i];
}
 
mais ca peut être n'importe quoi d'autre qui s'appuie en gros sur l'ordre de tes int ...
 
et non t'avais pas donné la méthode toString mais tu avais marqué tableau.toString(), ce qui laisse supposer que tu appelais la méthode toString() de base pour les objets tableaux  .

 
oui c'est vrai. Maintenant est-ce vraiment plus performant ?...sachant que je veux que la proba que deux tableaux différents aient le même hashCode soit faible . Si c'est juste pour éviter un parcours de tableau, alors par rapport à mon prog, le temps perdu est négligeable
Sinon, perso, j'essaie d'utiliser les fonctions de la bibliothèque autant que possible (si ce n'est pas pénalisant bien sûr )
 
 

 
Désolé pour la confusion alors   mais c'est bien une implémentation perso

bien sûr que c'est plus performant !  
compare les traitements effectués, c'est évident !
 
Au fait, j'avais pas bien regardé ta méthode toString ... C'est une catastrophe niveau perf !!

 
et tu proposerais quoi comme algo pour convertir le tableau en String ?  

1) je transformerais pas le tableau en String.
2) j'utiliserais un StringBuffer
3) je séparerais les int, parec que là {12,1}, {1, 21} et {1, 2, 1} sont transformés de la même façon

 
1) le StringBuffer permettrait de stocker une seule fois tous mes entiers si j'ai bien compris. Mais pour passer d'une permutation à une autre et ainsi générer un nouveau hashCode, tu t'y prendrais comment ?...tu vas lire ton StringBuffer caractère pas caractère ?    
 
2) Ensuite la classe StringBuffer n'a pas de méthode hashCode () d'implémenter, dans ce cas, il faudrait utiliser la tienne.
 
 
Bon maintenant que j'ai le net sur mon pc sur lequel je travaille, voilà le vrai code utilisé, de la méthode toString (), dans le programe (il est ressemblant) :

1) non t'as rien compris. StringBuffer permet juste de construire des chaines (par concaténation) de façon beaucoup plus efficaces que le +=
 
2) Ensuite, t'es pénible à voiloir appeler hashCode sur n'importe quoi. Je t'ai déjà dit que c'était pas la bonne solution de construire une chaine. Pourquoi tu t'obstines ?
 
et puis merde en fait ... j'arrête pas d'essayer de te guider dans la bonne direction et toi tu t'obstines...
 
Je te laisse donc te débrouiller avec tes String et tes hashcodes. Bon courage !

 
Les dessous des Strings

c'est bien intéressant ce que vous dîtes. Mais bon, moi qui débarque dans le Java, y'a rien de spécifier dans la doc. Je ne risque pas de savoir ce que benou a dit. La seul doc que j'utilise est la classique description de la librairie qui me sert :
 
http://java.sun.com/j2se/1.5.0/docs/api/index.html
 
Alors dire que je m'obstine c'est un peu facile quand je ne suis pas un javateux ésotérique. Les dessous de Java j'ai pas le temps de l'étudier en long en large et en travers (si faudrait faire ça pour tout les langages ca serait la mort).   .
S'il y aurait tant de différence au niveau perf. la javadoc le preciserai il me semble.  
Bon maintenant je vais aller voir le lien de nraynaud   .
 
et nraynaud > quand je lis la javadoc il est écrit noir sur blanc :

 
Alors, ben puisque ils le spécifient, je l'utilise.

1) tu es assez con pour croire la javadoc sur un point du langage, chapeau (cepandant, cette affirmation est vraie)
2) tu es trop con tout court.
 
Tu as interdiction de faire la moindre remarque sur les performances de java.  
 
J'espère que tu es au chomedu et que tu y restera ou que tu te fera virer pour incompétence rapidement.
 
 
Quand je pense à ce genre de réponse qui montre qu'on a absolument rien compris aux fondements de l'info et que moi on me propose d'aller faire des interfaces web dans une mutuelle, il y a vraiment quelquechose de pourri.
 
Tu es une merde.

ben alors pourquoi tu m'écoutes pas quand je te dis quelque chose ?
et la javadoc c'est une documentation sur l'API java, pas sur tout le langage.

 
c'est pas que je veux pas t'écouter mais les affirmations du style :
 

 
Ca m'apporte pas grand chose  

Je t'ai dis qu'il fallait pas passer par une String pour faire ton hashCode et qu'il fallait le calculer toi même à partir de ton tableau. C'est bon là c'est clair ???? je te dis ca depuis hier bon sang ! qu'est ce qu'il te faut ??? je t'ai même filé un exemple d'algo !
 
Je veux bien aider mais faut faire un minimum d'effort quand même, merde !

 
Houlala, j'ai vexé le javateux là  , mdr !  
Sinon, ce n'était même pas moi qui a fait cette fonction, je ne fais que poursuivre le développement    
Si on t'envoie faire des interfaces web dans une mutuelle c'est que t'es incompétent pour le reste peut être (sauf pour java   )
 
EDIT : et j'espère que tu travailleras beaucoup pour financer mon chômage  
 
EDIT 2 : tu mérites une sanction

c'est ça ouais, genre je suis soupçonnable d'âtre mono-langage ou mono-domaine ...
 

elle est amplement justifiée et non-encore répétée.

 
tu n'as qu'à insulter tout le monde de bon à rien aussi, et ça sera toujours justifié... . Et puis le "justifié" c'est subjectif ce truc, hein, ça veut rien dire.
 
PS : sinon, j'ai testé les "StringBuffer.append ()" contre les "String +=", bon y'a pas photo niveau perf . Mais bon, pour mon tableau de 100 int, on voit pas de différence.

non, TU es un boolay, ce qui n'est pas le cas de tout le monde ici.  
 
Et tu es un boolay non pas parce que tu débutes, mais bien parce que tu conteste ce que te disent des gens largement expérimenté dans le domaine que tu abordes, et que tu ne fais la différence entre "ça existe" (le + pour les chaines) et "il faut l'utiliser tout le temps" (ce qui n'est absolument pas le cas pour +, il faut l'utiliser avec prudence).
 
quand Benou te dit un truc sur la complexité de hashCode ou toString(), il a largement raison. Il a passé du temps à pondre et commenter des pavés, et tu n'écoutes toujours pas ses conseils avisés. Il est pourtant pas en train de te parler de collaborations complexes entre objets, mais bêtement des fonctions de Object, qui répondent aux besoins les plus basiques de java.
 
quand benou te propose (fort à-propos) un générateur congruant pour générer tes hash, tu lui réponds (à peu près) que générer le toString() puis faire le hashCode (qui est aussi un générateur congruant) de la chaine est plus rapide ... Si tu comprends rien à la complexité et aux performances, écoute-le, il connait lui ! Je prends la discussion en cours, je vois des concaténations douteuses (que Benou avait déjà soulignées d'ailleur), je file un topic que j'avais fait sur le sujet, lis-le pose des questions sur l'articulation de totu ça, mais ne vient pas sortir un bout de javadoc hors-contexte.

 
J'en conclus que tu ne comprends pas le français ? ou que tu es con ? ... ou les 2 ?