Souci avec le StringBuffer

Bonjour,

j'ai créé une classe qui gère des fichiers tabulés et elle fonctionne très bien. Là où je rencontre un problème, c'est avec la méthode qui écrit le contenu du fichier. Jusqu'à présent, j'avais surchargé la méthode toString et utilisé un StringBuffer, afin que la méthode me renvoit le contenu du fichier sous forme de chaîne de caractère :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

/** On surcharge la methode pour qu'elle renvoit le contenu du fichier tabule sous forme de chaine de caractere.  * @return Le fichier sous forme de chaines.*/ public String toString() { int i, j ; StringBuffer sb = new StringBuffer() ;   for (i=0 ; i < Largeur-1 ; i++) sb.append("\"" + NomColonnes[i] + "\"" + Separateur) ; sb.append("\"" + NomColonnes[Largeur-1] + "\"\n") ;   for (i=0 ; i < Hauteur ; i++) { for (j=0 ; j < Largeur-1 ; j++) switch ( TypeColonnes[j] ) { case INTEGER : sb.append(((int[])Tableau[j])[i] + Separateur) ; break ; case DOUBLE : sb.append(((double[])Tableau[j])[i] + Separateur) ; break ; case STRING : sb.append(((String[])Tableau[j])[i] + Separateur) ; break ; case INCONNU : sb.append("FichierTabuleSemiObjet.INCONNU" + Separateur) ; break ; default : throw new Error("Type de colonne invalide : " + TypeColonnes[j]) ; } switch ( TypeColonnes[Largeur-1] ) { case INTEGER : sb.append(((int[])Tableau[Largeur-1])[i] + "\n") ; break ; case DOUBLE : sb.append(((double[])Tableau[Largeur-1])[i] + "\n") ; break ; case STRING : sb.append(((String[])Tableau[Largeur-1])[i] + "\n") ; break ; case INCONNU : sb.append("FichierTabuleSemiObjet.INCONNU" + "\n") ; break ; default : throw new Error("Type de colonne invalide : " + TypeColonnes[Largeur-1]) ; } }   return sb.toString() ; }

---

Ce morceau de code fonctionne très bien, mais pour les gros fichiers, j'ai une jolie erreur "java.lang.OutOfMemoryError: Java heap space". Donc j'en déduis que le buffer est plein.

Je sais que je pourrais écrire mon fichier directement dans le fichier sortie sans utiliser un StringBuffer et ainsi résoudre mon problème. Donc j'ai une solution à mon problème.
Mais en étant honnête, j'aime bien le fait de surcharger la méthode toString et d'utiliser un StringBuffer. Alors j'aurai voulu savoir si vous aviez des solutions pour résoudre ce problème en gardant ma méthode...

Merci par avance.

Salut,

Pourquoi ne pas augmenter la taille de la memoire de ta JVM avec l'option -Xmx?
Puisque c'est elle qui est pleine, et non ton buffer.

A+
Hydraland

Bonjour,

effectivement, j'ai pour habitude d'utiliser -Xmx850M lors de ma compilation, donc je pensais que c'était le cas. Un bug d'eclipse vient de supprimer totalement l'option et je ne m'en étais pas rendu compte.
Donc c'est réglé.

Merci...

Salut,


Y-a-t-il une raison particulière pour que tu passes par un String ?
Si c'est seulement pour écrire dans un tableau j'ai du mal à en saisir l'intérêt, et l'écriture direct dans le fichier serait bien moins couteuse en mémoire !


Sinon, quelques remarques concernant ton code :

• Les nom d'attributs ne commencent pas par une majuscule en Java :(
  
• Si tu utilises Java 5 ou plus, tu peux remplacer StringBuffer par StringBuilder : c'est exactement la même chose mais non thread-safe (et donc potentiellement plus performant).
  
• Tu pourrais t'éviter le switch sur le type et utiliser un code générique en appelant directement append(Object) qui se sert de toString() :
  
  Code:

  ---

  sb.append(Tableau[i][j]);

  ---

  :arrow: Cela fonctionnera quel que soit le type de l'objet dans le tableau ;)
  
• Mis à part s'il s'agit de constantes, il est préférable d'utiliser plusieurs append() qu'un seul avec des concaténations avec + :
  
  Code:

  ---

  1 2 3 4 5

  sb.append("\"" + NomColonnes[i] + "\"" + Separateur) ;   // devient   sb.append("\"").append(NomColonnes[i]).append("\"").append(Separateur) ;

  ---

  :arrow: L'opérateur + génère des objets temporaires dont on peut se passer dans ce cas ;)

a++

Bonjour,

merci pour toutes ces remarques que je vais prendre en considération.

Ce n'est pas juste pour écrire, de temps en temps je souhaite afficher à la console le contenu de tout le tableau et la méthode toString était bien pour ça. Comme je l'ai marqué dans mon post d'introduction, je sais qu'il est plus rapide d'écrire directement dans le fichier :)

Pour le StrinBuider, je ne connaissais pas. Mais quand tu dis "potentiellement plus performant", je suis assez gêné par le "potentiellement" car on se demande alors si cela à réellement un intérêt.

J'ai corrigé en fonction de ta remarque entre les append et le +.

Mais je ne savais pas que la méthode append utilise directement la méthode toString. Comme j'utilise un tableau d'Object auquel je passe comme paramètre soit un tableau d'int, de double ou de String, j'aurai plutôt eu tendance à croire que la méthode toString aurait renvoyé l'adresse du pointeur sur le tableau plutôt que d'aller directement chercher la valeur de l'élément.

En tout cas merci...

Citation:

---

Envoyé par ToTo13

Mais je ne savais pas que la méthode append utilise directement la méthode toString. Comme j'utilise un tableau d'Object auquel je passe comme paramètre soit un tableau d'int, de double ou de String, j'aurai plutôt eu tendance à croire que la méthode toString aurait renvoyé l'adresse du pointeur sur le tableau plutôt que d'aller directement chercher la valeur de l'élément.

---

Cela dépend de la manière dont tu passes tes éléments : si tu passes seulement le tableau tu auras son adresse, mais si tu passes bien l'élément [i][j] alors tu auras bien le bon résultat...

Citation:

---

Envoyé par ToTo13

Pour le StrinBuider, je ne connaissais pas. Mais quand tu dis "potentiellement plus performant", je suis assez gêné par le "potentiellement" car on se demande alors si cela à réellement un intérêt.

---

Disons que comme tu utilises un StringBuffer en mono-thread, la synchronisation est effectué pour rien et StringBuilder permet de s'en passer.

Attention je ne dis pas que c'est mal d'utiliser StringBuffer bien au contraire c'est déjà un bon point :king:

Mais la synchronisation apporte un coût supplémentaire qui est inutile dans ton cas, même si dans bien des cas cela peut être assez minime...

Bref dans ton cas StringBuilder serait mieux si tu utilises Java 5.0

Citation:

---

Envoyé par ToTo13

Ce n'est pas juste pour écrire, de temps en temps je souhaite afficher à la console le contenu de tout le tableau et la méthode toString était bien pour ça. Comme je l'ai marqué dans mon post d'introduction, je sais qu'il est plus rapide d'écrire directement dans le fichier :)

---

Tu peux faire les deux assez facilement, par exemple en utilisant l'interface Appendable qui définit la méthode append() :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public void appendTo(Appendable out) throws IOException {   // Ton code qui fait tous les append dans "out"   }     public String toString() { try { StringBuilder sb = new StringBuilder(); this.appendTo(sb); return sb.toString(); } catch (IOException e) { // Ne devrais jamais arriver sur un StringBuilder // (mais on remonte l'exception par sécurité) throw new RuntimeException(e); } }

---

Le code de la méthode appendTo() sera grosso modo le même que celui de ton actuel toString(), si ce n'est que tu n'utiliseras pas de StringBuffer mais l'objet Appendable en paramètre. Il faudra juste que tu fasses les toString() par toi même car Appendable.append() n'accepte pas d'objet ou de type primitif.

Comme l'interface Appendable est implémenté par plusieurs classes dont StringBuffer/Builder, les différents Writers ou encore PrintStream, tu peux l'utiliser directement pour écrire directement dans un flux :

Code:

---

1 2 3 4 5 6

Writer w = new FileWriter("fichier.ext"); try { monobject.appendTo(w); } finally { w.close(); }

---

Mais tu pourras également utiliser toString(), ou mieux, écrire directement dans un flux. Par exemple :

Code:

---

System.out.println( monobjet );

---

Mais tu peux également faire :

Code:

---

monobjet.appendTo( System.out );

---

:arrow: Ce qui produira un résultat équivalent sans surcharger la mémoire ;)


a++

Bonjour,

ok, tu m'as convaincu pour le StringBuilder et je viens de modifier. D'autant plus qu'il suffit juste de modifier le nom et que j'utilise effectivement Java 5.0 (ai pas encore fait l'update :().

Pour ce qui est d'utiliser l'interface Appendable, c'est essentiellement pour s'abstraire d'un type. Ca n'apporte pas de réels avantages en terme de performance par rapport à ce que je fais.

A noter que je suis convaincu par l'utilisation d'un maximum d'abstraction pour avoir un maximum de généricité. J'essaie d'utiliser un maximum d'interface. Donc c'est juste pour bien comprendre les choses ;)

Citation:

---

Envoyé par ToTo13

Pour ce qui est d'utiliser l'interface Appendable, c'est essentiellement pour s'abstraire d'un type. Ca n'apporte pas de réels avantages en terme de performance par rapport à ce que je fais.

---

Oui tout à fait !

Une méthode qui écrit dans un StringBuilder est logiquement limité à un StringBuilder.
Mais les 3/4 du temps on se contente de faire des append() et on pourrait très bien utiliser l'interface Appendable de la sorte, ce qui permet d'utiliser par la suite n'importe quel type :D

a++

Bonjour,

ok parfait, maintenant je suis convaincu... donc je vais le faire :)

Bonjour,

en faisant les modifications, je rencontre un problème qui ne me plaît pas plus que ça. C'est surtout la solution que je ne n'aime pas.

Avant j'avais quelque chose de cette forme là :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

StringBuilder sb = new StringBuilder() ; ... switch ( TypeColonnes[j] ) { case INTEGER : sb.append(((int[])Tableau[j])[i]).append(Separateur) ; break ; case DOUBLE : sb.append(((double[])Tableau[j])[i]).append(Separateur) ; break ; case STRING : sb.append(((String[])Tableau[j])[i]).append(Separateur) ; break ; case INCONNU : sb.append("FichierTabuleSemiObjet.INCONNU").append(Separateur) ; break ; default : throw new Error("Type de colonne invalide : " + TypeColonnes[j]) ; }

---

Mais dans l'interface Appendable, on ne peut ajouter des type int ou double, donc je suis obligé de jouer avec les String.ValueOf :(

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public void appendTo(Appendable out) { ... switch ( TypeColonnes[j] ) { case INTEGER : out.append(String.valueOf(((int[])Tableau[j])[i])).append(Separateur) ; break ; case DOUBLE : out.append(String.valueOf(((double[])Tableau[j])[i])).append(Separateur) ; break ; case STRING : out.append(((String[])Tableau[j])[i]).append(Separateur) ; break ; case INCONNU : out.append("FichierTabuleSemiObjet.INCONNU").append(Separateur) ; break ; default : throw new Error("Type de colonne invalide : " + TypeColonnes[j]) ; }

---

Est ce que je ne perds pas trop en performance ?



Petite précision : mon tableau est de type Object, donc chaque élément contient un tableau (int[], double[], String[]) qui représente une colonne d'un fichier tabulé. Donc pas possible d'utiliser directement Tableau[i][j].

Citation:

---

Envoyé par ToTo13

Est ce que je ne perds pas trop en performance ?

---

Je ne pense pas puisque dans la doc de append(double) de StringBuffer/StringBuilder il est indiqué ceci :

Citation:

---

The argument is converted to a string as if by the method String.valueOf, and the characters of that string are then appended to this sequence.

---

Bref dans un cas c'est toi qui fait la conversion, et dans l'autre c'est la méthode append()...

a++

Merci...