Est-il préférable de réutiliser un StringBuilder dans une boucle?

J'ai une question relative aux performances concernant l'utilisation de StringBuilder. Dans une très longue boucle, je manipule un StringBuilderet le passe à une autre méthode comme celle-ci:

for (loop condition) {
    StringBuilder sb = new StringBuilder();
    sb.append("some string");
    . . .
    sb.append(anotherString);
    . . .
    passToMethod(sb.toString());
}

L'instanciation StringBuilderà chaque cycle de boucle est-elle une bonne solution? Et est-il préférable d'appeler une suppression, comme suit?

StringBuilder sb = new StringBuilder();
for (loop condition) {
    sb.delete(0, sb.length);
    sb.append("some string");
    . . .
    sb.append(anotherString);
    . . .
    passToMethod(sb.toString());
}

Le second est environ 25% plus rapide dans mon mini-benchmark.

public class ScratchPad {

    static String a;

    public static void main( String[] args ) throws Exception {
        long time = System.currentTimeMillis();
        for( int i = 0; i < 10000000; i++ ) {
            StringBuilder sb = new StringBuilder();
            sb.append( "someString" );
            sb.append( "someString2"+i );
            sb.append( "someStrin4g"+i );
            sb.append( "someStr5ing"+i );
            sb.append( "someSt7ring"+i );
            a = sb.toString();
        }
        System.out.println( System.currentTimeMillis()-time );
        time = System.currentTimeMillis();
        StringBuilder sb = new StringBuilder();
        for( int i = 0; i < 10000000; i++ ) {
            sb.delete( 0, sb.length() );
            sb.append( "someString" );
            sb.append( "someString2"+i );
            sb.append( "someStrin4g"+i );
            sb.append( "someStr5ing"+i );
            sb.append( "someSt7ring"+i );
            a = sb.toString();
        }
        System.out.println( System.currentTimeMillis()-time );
    }
}

Résultats:

25265
17969

Notez que c'est avec JRE 1.6.0_07.

Basé sur les idées de Jon Skeet dans l'édition, voici la version 2. Même résultats.

public class ScratchPad {

    static String a;

    public static void main( String[] args ) throws Exception {
        long time = System.currentTimeMillis();
        StringBuilder sb = new StringBuilder();
        for( int i = 0; i < 10000000; i++ ) {
            sb.delete( 0, sb.length() );
            sb.append( "someString" );
            sb.append( "someString2" );
            sb.append( "someStrin4g" );
            sb.append( "someStr5ing" );
            sb.append( "someSt7ring" );
            a = sb.toString();
        }
        System.out.println( System.currentTimeMillis()-time );
        time = System.currentTimeMillis();
        for( int i = 0; i < 10000000; i++ ) {
            StringBuilder sb2 = new StringBuilder();
            sb2.append( "someString" );
            sb2.append( "someString2" );
            sb2.append( "someStrin4g" );
            sb2.append( "someStr5ing" );
            sb2.append( "someSt7ring" );
            a = sb2.toString();
        }
        System.out.println( System.currentTimeMillis()-time );
    }
}

Résultats:

5016
7516

Dans la philosophie de l'écriture de code solide, il est toujours préférable de mettre votre StringBuilder dans votre boucle. De cette façon, il ne sort pas du code pour lequel il est destiné.

Deuxièmement, la plus grande amélioration de StringBuilder vient de lui donner une taille initiale pour éviter qu'elle ne s'agrandisse pendant que la boucle tourne

for (loop condition) {
  StringBuilder sb = new StringBuilder(4096);
}

Toujours plus vite:

public class ScratchPad {

    private static String a;

    public static void main( String[] args ) throws Exception {
        long time = System.currentTimeMillis();
        StringBuilder sb = new StringBuilder( 128 );

        for( int i = 0; i < 10000000; i++ ) {
            // Resetting the string is faster than creating a new object.
            // Since this is a critical loop, every instruction counts.
            //
            sb.setLength( 0 );
            sb.append( "someString" );
            sb.append( "someString2" );
            sb.append( "someStrin4g" );
            sb.append( "someStr5ing" );
            sb.append( "someSt7ring" );
            setA( sb.toString() );
        }

        System.out.println( System.currentTimeMillis()-time );
    }

    private static void setA( String aString ) {
        a = aString;
    }
}

Dans la philosophie de l'écriture de code solide, le fonctionnement interne de la méthode doit être caché des objets qui utilisent la méthode. Ainsi, il ne fait aucune différence du point de vue du système si vous redéclarez le StringBuilder dans la boucle ou en dehors de la boucle. Comme le déclarer en dehors de la boucle est plus rapide et que cela ne complique pas la lecture du code, réutilisez l'objet plutôt que de le réinstituer.

Même si le code était plus compliqué et que vous saviez avec certitude que l'instanciation d'objet était le goulot d'étranglement, commentez-le.

Trois courses avec cette réponse:

$ java ScratchPad
1567
$ java ScratchPad
1569
$ java ScratchPad
1570

Trois courses avec l'autre réponse:

$ java ScratchPad2
1663
2231
$ java ScratchPad2
1656
2233
$ java ScratchPad2
1658
2242

Bien que cela ne soit pas significatif, le réglage de la StringBuildertaille initiale du tampon donnera un petit gain.

D'accord, je comprends maintenant ce qui se passe, et cela a du sens.

J'avais l'impression que toStringje venais de passer le sous-jacent char[]dans un constructeur String qui ne prenait pas de copie. Une copie serait alors faite lors de la prochaine opération "d'écriture" (par exemple delete). Je pense que c'était le cas StringBufferdans certaines versions précédentes. (Ce n'est pas le cas maintenant.) Mais non - toStringpasse simplement le tableau (ainsi que l'index et la longueur) au Stringconstructeur public qui prend une copie.

Donc, dans le cas "réutiliser le StringBuilder", nous créons véritablement une copie des données par chaîne, en utilisant le même tableau de caractères dans le tampon tout le temps. Évidemment, créer un nouveau à StringBuilderchaque fois crée un nouveau tampon sous-jacent - puis ce tampon est copié (quelque peu inutile, dans notre cas particulier, mais fait pour des raisons de sécurité) lors de la création d'une nouvelle chaîne.

Tout cela conduit à ce que la deuxième version soit définitivement plus efficace - mais en même temps, je dirais toujours que c'est un code plus laid.

Comme je ne pense pas que cela ait encore été souligné, en raison des optimisations intégrées au compilateur Sun Java, qui crée automatiquement StringBuilders (StringBuffers pré-J2SE 5.0) lorsqu'il voit des concaténations de chaînes, le premier exemple de la question est équivalent à:

for (loop condition) {
  String s = "some string";
  . . .
  s += anotherString;
  . . .
  passToMethod(s);
}

Ce qui est plus lisible, l'OMI, la meilleure approche. Vos tentatives d'optimisation peuvent entraîner des gains sur certaines plates-formes, mais potentiellement en perdre d'autres.

Mais si vous rencontrez vraiment des problèmes de performances, alors optimisez-les. Je commencerais par spécifier explicitement la taille de la mémoire tampon du StringBuilder, par Jon Skeet.

La JVM moderne est vraiment intelligente pour ce genre de choses. Je ne le devinerais pas et ne ferais pas quelque chose de piraté qui soit moins maintenable / lisible ... à moins que vous ne fassiez de bons repères avec des données de production qui valident une amélioration de performance non triviale (et la documentent;)

Sur la base de mon expérience avec le développement de logiciels sur Windows, je dirais que l'effacement de StringBuilder pendant votre boucle a de meilleures performances que l'instanciation d'un StringBuilder à chaque itération. L'effacer libère cette mémoire pour être écrasée immédiatement sans allocation supplémentaire requise. Je ne suis pas assez familier avec le ramasse-miettes Java, mais je pense que la libération et aucune réallocation (à moins que votre prochaine chaîne ne développe le StringBuilder) est plus bénéfique que l'instanciation.

(Mon opinion est contraire à ce que tout le monde suggère. Hmm. Il est temps de le comparer.)

La raison pour laquelle faire un 'setLength' ou 'delete' améliore les performances est principalement le code 'apprenant' la bonne taille du tampon, et moins pour faire l'allocation de mémoire. En général, je recommande de laisser le compilateur faire les optimisations de chaîne . Cependant, si les performances sont critiques, je pré-calcule souvent la taille attendue du tampon. La taille par défaut de StringBuilder est de 16 caractères. Si vous vous développez au-delà de cela, alors il doit être redimensionné. Le redimensionnement est l'endroit où les performances se perdent. Voici un autre mini-benchmark qui illustre cela:

private void clear() throws Exception {
    long time = System.currentTimeMillis();
    int maxLength = 0;
    StringBuilder sb = new StringBuilder();

    for( int i = 0; i < 10000000; i++ ) {
        // Resetting the string is faster than creating a new object.
        // Since this is a critical loop, every instruction counts.
        //
        sb.setLength( 0 );
        sb.append( "someString" );
        sb.append( "someString2" ).append( i );
        sb.append( "someStrin4g" ).append( i );
        sb.append( "someStr5ing" ).append( i );
        sb.append( "someSt7ring" ).append( i );
        maxLength = Math.max(maxLength, sb.toString().length());
    }

    System.out.println(maxLength);
    System.out.println("Clear buffer: " + (System.currentTimeMillis()-time) );
}

private void preAllocate() throws Exception {
    long time = System.currentTimeMillis();
    int maxLength = 0;

    for( int i = 0; i < 10000000; i++ ) {
        StringBuilder sb = new StringBuilder(82);
        sb.append( "someString" );
        sb.append( "someString2" ).append( i );
        sb.append( "someStrin4g" ).append( i );
        sb.append( "someStr5ing" ).append( i );
        sb.append( "someSt7ring" ).append( i );
        maxLength = Math.max(maxLength, sb.toString().length());
    }

    System.out.println(maxLength);
    System.out.println("Pre allocate: " + (System.currentTimeMillis()-time) );
}

public void testBoth() throws Exception {
    for(int i = 0; i < 5; i++) {
        clear();
        preAllocate();
    }
}

Les résultats montrent que la réutilisation de l'objet est environ 10% plus rapide que la création d'un tampon de la taille attendue.

LOL, la première fois que j'ai vu des gens comparer les performances en combinant une chaîne dans StringBuilder. Pour cela, si vous utilisez "+", cela pourrait être encore plus rapide; D. Le but d'utiliser StringBuilder pour accélérer la récupération de la chaîne entière en tant que concept de «localité».

Dans le scénario où vous récupérez fréquemment une valeur de chaîne qui ne nécessite pas de modification fréquente, Stringbuilder permet de meilleures performances de récupération de chaîne. Et c'est le but de l'utilisation de Stringbuilder .. s'il vous plaît ne pas MIS-Test le but principal de cela.

Certaines personnes ont dit, l'avion vole plus vite. Par conséquent, je l'ai testé avec mon vélo et j'ai constaté que l'avion se déplaçait plus lentement. Savez-vous comment je règle les paramètres de l'expérience; D

Pas beaucoup plus rapide, mais d'après mes tests, il montre en moyenne quelques millis de temps plus rapide en utilisant 1.6.0_45 64 bits: utilisez StringBuilder.setLength (0) au lieu de StringBuilder.delete ():

time = System.currentTimeMillis();
StringBuilder sb2 = new StringBuilder();
for (int i = 0; i < 10000000; i++) {
    sb2.append( "someString" );
    sb2.append( "someString2"+i );
    sb2.append( "someStrin4g"+i );
    sb2.append( "someStr5ing"+i );
    sb2.append( "someSt7ring"+i );
    a = sb2.toString();
    sb2.setLength(0);
}
System.out.println( System.currentTimeMillis()-time );

Le moyen le plus rapide est d'utiliser "setLength". Cela n'impliquera pas l'opération de copie. La façon de créer un nouveau StringBuilder devrait être complètement abandonnée . La lenteur de StringBuilder.delete (int start, int end) est due au fait qu'il recopiera le tableau pour la partie redimensionnée.

 System.arraycopy(value, start+len, value, start, count-end);

Après cela, StringBuilder.delete () mettra à jour StringBuilder.count à la nouvelle taille. Alors que StringBuilder.setLength () simplifie simplement la mise à jour de StringBuilder.count à la nouvelle taille.

Le premier est meilleur pour les humains. Si la seconde est un peu plus rapide sur certaines versions de certaines JVM, et alors?

Si les performances sont si critiques, contournez StringBuilder et écrivez les vôtres. Si vous êtes un bon programmeur et que vous tenez compte de la façon dont votre application utilise cette fonction, vous devriez pouvoir la rendre encore plus rapide. Digne d'intérêt? Probablement pas.

Pourquoi cette question est-elle considérée comme "question préférée"? Parce que l'optimisation des performances est tellement amusante, qu'elle soit pratique ou non.

Je ne pense pas qu'il soit logique d'essayer d'optimiser les performances comme ça. Aujourd'hui (2019), les deux états fonctionnent environ 11sec pour 100.000.000 de boucles sur mon ordinateur portable I5:

    String a;
    StringBuilder sb = new StringBuilder();
    long time = 0;

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        StringBuilder sb3 = new StringBuilder();
        sb3.append("someString");
        sb3.append("someString2");
        sb3.append("someStrin4g");
        sb3.append("someStr5ing");
        sb3.append("someSt7ring");
        a = sb3.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        sb.setLength(0);
        sb.delete(0, sb.length());
        sb.append("someString");
        sb.append("someString2");
        sb.append("someStrin4g");
        sb.append("someStr5ing");
        sb.append("someSt7ring");
        a = sb.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

==> 11000 ms (déclaration à l'intérieur de la boucle) et 8236 ms (déclaration à l'extérieur de la boucle)

Même si je suis en train d'exécuter des programmes de dédoublement d'adresses avec quelques milliards de boucles, une différence de 2 sec. pour 100 millions de boucles ne fait aucune différence car ces programmes fonctionnent pendant des heures. Sachez également que les choses sont différentes si vous n'avez qu'une seule instruction d'ajout:

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        StringBuilder sb3 = new StringBuilder();
        sb3.append("someString");
            a = sb3.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        sb.setLength(0);
        sb.delete(0, sb.length());
        sb.append("someString");
        a = sb.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

==> 3416 ms (boucle intérieure), 3555 ms (boucle extérieure) La première instruction qui crée le StringBuilder dans la boucle est plus rapide dans ce cas. Et, si vous changez l'ordre d'exécution, c'est beaucoup plus rapide:

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        sb.setLength(0);
        sb.delete(0, sb.length());
        sb.append("someString");
        a = sb.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

    System.gc();
    time = System.currentTimeMillis();
    for (int i = 0; i < 100000000; i++) {
        StringBuilder sb3 = new StringBuilder();
        sb3.append("someString");
            a = sb3.toString();
    }
    System.out.println(System.currentTimeMillis() - time);

==> 3638 msec (boucle extérieure), 2908 msec (boucle intérieure)

Cordialement, Ulrich

Déclarez une fois et attribuez-les à chaque fois. C'est un concept plus pragmatique et réutilisable qu'une optimisation.