Лучше ли повторно использовать StringBuilder в цикле?

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

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

Во-вторых, самое большое улучшение в StringBuilder заключается в том, что ему был задан начальный размер, чтобы он не увеличивался во время выполнения цикла.

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

Основываясь на моем опыте разработки программного обеспечения в Windows, я бы сказал, что очистка StringBuilder во время вашего цикла дает лучшую производительность, чем создание экземпляра StringBuilder на каждой итерации. Его очистка освобождает эту память для немедленной перезаписи без дополнительных выделений. Я недостаточно знаком с сборщиком мусора Java, но я думаю, что освобождение и отсутствие перераспределения (если ваша следующая строка не увеличивает StringBuilder) более выгодно, чем создание экземпляра.

(Мое мнение противоречит тому, что предлагают все остальные. Хм. Пора проверить это.)

Второй примерно на 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

Хорошо, теперь я понимаю, что происходит, и это имеет смысл.

У меня создалось впечатление, что toString просто передал базовый char[] в конструктор String, который не сделал принимает копию. Затем копия будет сделана при следующей операции «записи» (например, delete). Я считаю, что это был случай с StringBuffer в какой-то предыдущей версии. (Сейчас это не так.) Но нет - toString просто передает массив (а также индекс и длину) общедоступному конструктору String, который принимает копию.

Таким образом, в случае «повторного использования StringBuilder» мы действительно создаем одну копию данных для каждой строки, все время используя один и тот же массив символов в буфере. Очевидно, что создание нового StringBuilder каждый раз создает новый базовый буфер, а затем этот буфер копируется (несколько бессмысленно, в нашем конкретном случае, но делается по соображениям безопасности) при создании новой строки.

Все это приводит к тому, что вторая версия определенно более эффективна, но в то же время я бы сказал, что это более уродливый код.

Объявить один раз и назначить каждый раз. Это более прагматичная и многоразовая концепция, чем оптимизация.

Первый лучше для людей. Если второй работает немного быстрее на некоторых версиях некоторых JVM, что с того?

Если производительность настолько критична, обойдите StringBuilder и напишите свой собственный. Если вы хороший программист и примете во внимание, как ваше приложение использует эту функцию, вы сможете сделать это еще быстрее. Стоит? Возможно нет.

Почему этот вопрос обозначен как «любимый вопрос»? Потому что оптимизация производительности - это очень весело, независимо от того, практично это или нет.

Поскольку я не думаю, что на это еще указывалось, из-за оптимизации, встроенной в компилятор Sun Java, который автоматически создает StringBuilders (StringBuffers pre-J2SE 5.0), когда видит конкатенации строк, первый пример в вопросе эквивалентен:

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

Что более читабельно, ИМО, тем лучше. Ваши попытки оптимизации могут привести к выигрышу для одной платформы, но потенциально к потерям для других.

Но если вы действительно сталкиваетесь с проблемами с производительностью, тогда, конечно, оптимизируйте. Я бы начал с явного указания размера буфера StringBuilder, как сказал Джон Скит.

Еще быстрее:

public class ScratchPad {

    private static String a;

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

        // Pre-allocate enough space to store all appended strings.
        // StringBuilder, ultimately, uses an array of characters.
        final 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( final 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 для предотвращения перераспределения памяти даст небольшой прирост производительности.

Причина, по которой выполнение setLength или delete улучшает производительность, в основном заключается в том, что код «изучает» правильный размер буфера, а не в распределении памяти. Обычно Я рекомендую позволить компилятору выполнить оптимизацию строк. Однако, если производительность критична, я часто заранее рассчитываю ожидаемый размер буфера. Размер 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-Test его основную цель ..

Некоторые говорили: «Самолет летит быстрее». Поэтому я протестировал это на своем байке и обнаружил, что самолет движется медленнее. Вы знаете, как я выставляю настройки эксперимента? D

Не значительно быстрее, но из моих тестов показывает, что в среднем на пару миллисек быстрее при использовании 1.6.0_45 64 бит: используйте 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 до нового размера.

Я не думаю, что имеет смысл пытаться таким образом оптимизировать производительность. Сегодня (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 мс (внутренний цикл)

С уважением, Ульрих