Performancer : StringBuffer

Marsh Posté le 09-10-2002 à 11:10:23

Question toute bête. Selon vous, laquelle de ces 2 boucles est la plus performante :
1 :

Code :

StringBuffer myBuf = new StringBuffer ();
StringBuffer mySecondBuf = new StringBuffer ();
for (int i = 0; i < 10; i++) {
myBuf.append ("un truc" ).append ("plein d'autres trucs" );
mySecondBuf.append (myBuf.toString ());
myBuf.delete(0, myBuf.length());
}

2 :

Code :

StringBuffer myBuf;
StringBuffer mySecondBuf = new StringBuffer ();
for (int i = 0; i < 10; i++) {
myBuf = new StringBuffer ();
myBuf.append ("un truc" ).append ("plein d'autres trucs" );
mySecondBuf.append (myBuf.toString ());
}

Message édité par El_gringo le 09-10-2002 à 11:19:35

Reply

Marsh Posté le 09-10-2002 à 11:10:23

Reply

Marsh Posté le 09-10-2002 à 11:12:30

Ca marche, ça ??? C'est pour faire quoi exactement ? Ca me semble très foireux les 2 .append cascadés...

Reply

Marsh Posté le 09-10-2002 à 11:15:02

_Mac_ a écrit a écrit :

Ca marche, ça ??? C'est pour faire quoi exactement ? Ca me semble très foireux les 2 .append cascadés...

Bah, append rend un StringBuffer, y a aucune raison que ça marche pas ! :??:

EDIT : Et puis c pas important ça. La g écrit ça juste pour illustrer ma question. L'important, c'est : créer un nouveau StringBuffer à chaque ittération, ou effacer le contenu d'une seule instance ?

Message édité par El_gringo le 09-10-2002 à 11:20:12

Reply

Marsh Posté le 09-10-2002 à 11:26:11

A mon avis, la solution 1 est plus rationnelle : elle chargera moins la mémoire et sera moins couteuse en CPU car l'instanciation est un mécanisme assez lourd.

Mais pourquoi utilises-tu 2 StringBuffer ??? 1 seul suffit, a mon avis.

Reply

Marsh Posté le 09-10-2002 à 11:31:41

_Mac_ a écrit a écrit :

A mon avis, la solution 1 est plus rationnelle : elle chargera moins la mémoire et sera moins couteuse en CPU car l'instanciation est un mécanisme assez lourd.

Mais pourquoi utilises-tu 2 StringBuffer ??? 1 seul suffit, a mon avis.

Dans l'exemple que j'ai donné, évidement que ça suffirait, Mais ma situation est telle qu'il me parait logique d'utiliser 2 StringBuffer.
A priori, j'pense aussi que la solution 1 est la meilleur. Mais j'attend qd même qqs autres avis...

Reply

Marsh Posté le 09-10-2002 à 12:50:10

Le méthode par new est un peu plus rapide. Elle le sera d'autant plus si tu connais un majorant de la taille maximum que prendra ton StringBuffer temporaire.

Le problème du delete() est qu'il fait une copie de tableau systématique (et même pas par un System.arraycopy(), d'après les sources du J2SDK ! :ouch: ) .

Il y a de toute façon plus rapide que delete() si tu n'aimes pas la méthode new(): fais un myBuf.setLength(0)...

Reply

Marsh Posté le 09-10-2002 à 14:16:33

Mais j'ai rien contre la méthode New moi. Juste, je me disais qu'en faisant plein de new, je vais avoir plein d'instances "poubelle" (sans référence dessus !), et qu'elles risques de surcharger la mémoire en attendant d'être détruites par la garbage collector. Mais là, je dis peut être des conneries.

Reply

Marsh Posté le 09-10-2002 à 15:14:47

El_Gringo a écrit a écrit :

Mais j'ai rien contre la méthode New moi. Juste, je me disais qu'en faisant plein de new, je vais avoir plein d'instances "poubelle" (sans référence dessus !), et qu'elles risques de surcharger la mémoire en attendant d'être détruites par la garbage collector. Mais là, je dis peut être des conneries.

C'est possible, mais le garbage collector de la JVM de Sun est assez agressif de ce point de vue (quant à HotSpot Server, je n'en parle même pas... il l'est encore plus). Ca ne m'étonnerait pas qu'il soit capable de détecter la courte portée du StringBuffer temporaire et qu'il le désalloue aussi vite que tu en alloues de nouveau.

Mais la solution StringBuffer.setLength(0) me semble assez simple et élégante pour contourner tes craintes.

Reply

Marsh Posté le 09-10-2002 à 15:35:18

Bon, ben c parti alors.
Merci...

Reply

Performancer : StringBuffer

Sujets relatifs:

Leave a Replay