Почему StringBuilder.setLength(0) медленнее чем ожидается?

Question

[Beholder]

Прочитал статью Clearing a StringBuilder or StringBuffer и сначала не поверил, но проверил сам - и это действительно так. StringBuilder.setLength(0) чуть ли не в два раза медленнее, чем StringBuilder.delete(0, sb.length()). Проверил на Open JDK 17. Отчего так? setLength(0) же никаких массивов на самом деле не обнуляет, а только устанавливает счётчик.

Answer 1

[mayton2019]

А как вы измеряли? Методика бенчмарков в Java - нетривиальна. Тут надо попасть в прогретый код и в промежутки между паузами GC. Иначе ваш эскперимент будет выдавать вовсе не то время что вы хотите мерять.

Comments

[Elmo Sputterspark]

Автор приведённой в вопросе статьи с JMH проверял.

[mayton2019]

Я тут глянул в исходники OpenJDK (мастер ветка по состоянию на Jul 11)

Тут - не просто обнуление счетчика. Тут надо ... подумать. Крепко подумать.
AbstractStringBuilder.java

public void setLength(int newLength) {
        if (newLength < 0) {
            throw new StringIndexOutOfBoundsException(newLength);
        }
        ensureCapacityInternal(newLength);
        if (count < newLength) {
            if (isLatin1()) {
                StringLatin1.fillNull(value, count, newLength);
            } else {
                StringUTF16.fillNull(value, count, newLength);
            }
        } else if (count > newLength) {
            maybeLatin1 = true;
        }
        count = newLength;
    }

public AbstractStringBuilder delete(int start, int end) {
        int count = this.count;
        if (end > count) {
            end = count;
        }
        Preconditions.checkFromToIndex(start, end, count, Preconditions.SIOOBE_FORMATTER);
        int len = end - start;
        if (len > 0) {
            shift(end, -len);
            this.count = count - len;
            maybeLatin1 = true;
        }
        return this;
    }

[Beholder]

mayton2019, В первом исходнике ветка if (count < newLength) не срабатывает, ветки else if (count > newLength) в JDK 17 ещё нет. Остаются только две проверки и присваивание count = newLength; Во втором исходнике тоже две проверки. Вот и в чём принципиальная разница?

[mayton2019]

Beholder, не знаю. Надо смотреть что там по коду. Что делает эта штука.
ensureCapacityInternal(..)

Для меня - сама тема исследования странная. И я не помню когда я вообще использовал метод setLength. Может это такой редкий кейс что и никому он не интересен.

Кстати я не согласен с обнулением кумулятивной строки. Уж если-бы я делал генератор строк под нагрузкой - то я-бы исследовал 95-й процентиль от длины моих строк. И я уверен что это был-бы не ноль а какая-от вменяемая средняя длина. Например 30 или 50 символов. Кому нужен СтрингБилдер который стартует с нуля? Ясен пень что он все равно будет экстендится. И ясен пень не по 1 символу. Там алгоритм оперирует более крупными кусками. Так дайте ему сразу кусок!

Answer 2

[Elmo Sputterspark]

А ты посмотри исходный код обоих методов и сразу всё станет понятно. Метод delete вызывает написанную на C функцию arraycopy, которая с параметрами передаваемыми в неё при аргументах 0 и sb.length не делает ничего и сразу возвращает управление. Метод setLength сначала делает вызов другого метода ensureCapacityInternal, который проверяет текущую длину массива, и только потом устанавливает новый размер. Во втором случае тупо больше вызовов и каждый из них медленнее, чем arraycopy с нулевым параметром length.