Чи краще повторно використовувати StringBuilder у циклі?

У мене питання щодо продуктивності щодо використання StringBuilder. У дуже довгому циклі я маніпулюю StringBuilderта передаю його іншому способу, як це:

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

Чи StringBuilderвдале рішення для кожного циклу циклу - це гарне рішення? І чи викликає замість цього видалення краще, як у наступному?

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

Другий - приблизно на 25% швидше в моєму міні-орієнтирі.

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 );
    }
}

Результати:

25265
17969

Зауважте, що це стосується JRE 1.6.0_07.

На основі ідей Джона Скіта в редагуванні, ось версія 2. Хоча однакові результати.

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 );
    }
}

Результати:

5016
7516

У філософії написання твердого коду завжди краще помістити StringBuilder всередину вашого циклу. Таким чином він не виходить за межі коду, призначеного для нього.

По-друге, найбільша поліпшення в StringBuilder виходить від надання йому початкового розміру, щоб уникнути його збільшення, поки цикл працює

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

Ще швидше:

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;
    }
}

У філософії написання твердого коду внутрішня робота методу повинна бути прихована від об'єктів, які використовують метод. Таким чином, з точки зору системи не має жодної різниці, переоголошуєте ви StringBuilder в циклі або поза ним. Оскільки оголошення його за межами циклу відбувається швидше, і це не робить код складнішим для читання, то використовуйте об'єкт повторно, а не повторно інстантуйте його.

Навіть якщо код був складнішим, і ви точно знали, що екземпляром об'єкта є вузьке місце, прокоментуйте його.

Три відповіді з цією відповіддю:

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

Три пробіжки з іншою відповіддю:

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

Хоча це не суттєво, встановлення StringBuilderпочаткового розміру буфера дасть невеликий приріст.

Гаразд, я зараз розумію, що відбувається, і це має сенс.

У мене було враження, що toStringякраз перейшов основу char[]в конструктор String, який не взяв копію. Потім буде зроблена копія при наступній операції "запис" (наприклад delete). Я вважаю, що так було і StringBufferв попередній версії. (Це не зараз.) Але ні - toStringпросто передає масив (та індекс та довжину) громадському Stringконструктору, який бере копію.

Тож у випадку "повторного використання StringBuilder" ми справді створюємо одну копію даних на рядок, використовуючи той самий масив char у буфері весь час. Очевидно, що створюючи новий, StringBuilderкожен раз створюється новий базовий буфер - і тоді цей буфер копіюється (дещо безглуздо, в нашому конкретному випадку, але робиться з міркувань безпеки) під час створення нового рядка.

Все це призводить до того, що друга версія, безумовно, є більш ефективною, але в той же час я все одно скажу, що це потворніший код.

Оскільки я не думаю, що це ще не було зазначено, через оптимізації, вбудовані в компілятор Sun Java, який автоматично створює StringBuilders (StringBuffers pre-J2SE 5.0), коли він бачить об'єднання String, перший приклад у питанні еквівалентний:

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

Що легше читати, ІМО, тим краще підходити. Ваші спроби оптимізації можуть призвести до виграшів на одній платформі, але потенційно можуть втратити інші.

Але якщо ви справді стикаєтеся з проблемами з продуктивністю, то впевнено оптимізуйте. Я б почав із чіткого визначення розміру буфера StringBuilder, за Jon Skeet.

Сучасний JVM дуже розумний до подібних речей. Я б не другий здогад про це і зробив щось гакістне, що є менш досяжним / читабельним ... якщо тільки ви не зробите належну оцінку з виробничими даними, які підтверджують нетривіальне поліпшення продуктивності (і документуйте це;)

Виходячи з мого досвіду розробки програмного забезпечення в Windows, я б сказав, що очищення StringBuilder під час циклу має кращу ефективність, ніж інстанціювання StringBuilder з кожною ітерацією. Після її очищення пам'ять потрібно негайно перезаписати, не потребуючи додаткового виділення. Я недостатньо знайомий зі збирачем сміття Java, але думаю, що звільнення та перерозподіл (якщо ваша наступна рядок не зростає StringBuilder) є більш корисним, ніж інстанція.

(Моя думка суперечить тому, що всі інші пропонують. Хм. Час орієнтуватися на це.)

Причиною, чому виконання "setLength" або "видалення" покращує продуктивність, здебільшого є кодом "навчання" правильного розміру буфера, а менше - для розподілу пам'яті. Як правило, я рекомендую дозволити компілятору робити оптимізацію рядків . Однак якщо продуктивність є критичною, я часто заздалегідь обчислюю очікуваний розмір буфера. Стандартний розмір StringBuilder - 16 символів. Якщо ви зростаєте за рамки цього, то воно має змінити розмір. Змінення розміру - це те, де продуктивність втрачається. Ось ще один міні-орієнтир, який ілюструє це:

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();
    }
}

Результати показують повторне використання об'єкта приблизно на 10% швидше, ніж створення буфера очікуваного розміру.

LOL, я вперше бачив, як люди порівнювали продуктивність, поєднуючи рядок у StringBuilder. З цією метою, якщо ви використовуєте "+", це може бути ще швидше; D. Мета використання StringBuilder для прискорення пошуку всього рядка як поняття "локальність".

У випадку, коли ви часто отримуєте значення String, яке не потребує частого зміни, Stringbuilder дозволяє підвищити ефективність пошуку рядків. І це є метою використання Stringbuilder .. будь ласка, не MIS-тестуйте основну мету цього ..

Деякі люди казали: Літак летить швидше. Тому я перевіряв його на своєму велосипеді, і виявив, що літак рухається повільніше. Чи знаєте ви, як я встановлюю параметри експерименту; D

Не значно швидше, але з моїх тестів це показує, що в середньому на пару мілісів швидше, використовуючи 64.0 біт 1.6.0_45: використовуйте StringBuilder.setLength (0) замість 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 );

Найшвидший спосіб - це використовувати "setLength". Він не буде включати операцію копіювання. Шлях створення нового StringBuilder повинен бути повністю вичерпаний . Повільне для StringBuilder.delete (int start, int end) відбувається тому, що воно знову копіює масив для зміни розміру частини.

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

Після цього StringBuilder.delete () оновить StringBuilder.count до нового розміру. У той час як StringBuilder.setLength () просто спростіть оновити StringBuilder.count до нового розміру.

Перший краще для людей. Якщо другий трохи швидший на деяких версіях деяких JVM, то що?

Якщо продуктивність настільки важлива, обійдіть StringBuilder і напишіть своє. Якщо ви хороший програміст і враховуєте, як ваш додаток використовує цю функцію, ви зможете зробити це ще швидше. Варто? Напевно, ні.

Чому це питання розглядається як "улюблене питання"? Оскільки оптимізація продуктивності - це дуже цікаво, незалежно від того, практична вона чи ні.

Я не думаю, що це має сенс намагатися оптимізувати подібну ефективність. Сьогодні (2019 р.) Обидва тиски працюють близько 11 сек на 100 000 000 циклів на моєму ноутбуці 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 мсек (декларація всередині циклу) і 8236 мсек (оголошення зовнішньої петлі)

Навіть якщо я запускаю програми для дедублікації адреси з кількома мільярдами циклів різницею в 2 сек. для 100 мільйонів циклів не має ніякої різниці, оскільки ці програми працюють годинами. Також пам’ятайте, що все є інакше, якщо у вас є лише одне додаток:

    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 мсек (внутрішній цикл), 3555 мсек (зовнішній цикл) Перше твердження, яке створює StringBuilder в циклі, швидше в цьому випадку. І, якщо ви зміните порядок виконання, це набагато швидше:

    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 мсек (зовнішня петля), 2908 мсек (внутрішня петля)

З повагою, Ульріх

Декларуйте один раз і призначте кожен раз. Це більш прагматична і багаторазова концепція, ніж оптимізація.