Главная > Java сниппеты > Конкатенация строк и производительность

Тема Зацепин
268

Java-разработчик 🧩
515
1 минуту

Конкатенация строк и производительность

1 Введение 2 Разница в "+" и StringBuffer 3 Поясняющий пример 4 Расшифровка результатов 5 Ссылки

Добавлено : 19 Mar 2009, 18:01

Содержание

Введение

Советы от 5 февраля 2002 "Запись методов toString" (источник и перевод на JavaGu.ru) включали следующее предложение:

Обратите внимание, что использование "+" в toString для построения возвращаемого значения не всегда является самым эффективным подходом. Возможно, вы захотите использовать вместо этого StringBuffer.

Читатель технических советов отметил, что в документации по Java говорится о том, что для фактической реализации оператора + применяется StringBuffer. Поэтому возникает вопрос, какой выигрыш в производительности, если он существует, вы получите при явном использовании StringBuffer в ваших программах? В этой статье делается попытка ответить на этот вопрос.

Для начала рассмотрим пример, в котором строка формируется путем повторения одного и того же символа:

class MyTimer {
private final long start;

public MyTimer() {
start = System.currentTimeMillis();
}

public long getElapsed() {
return System.currentTimeMillis() - start;
}
}

public class AppDemo1 {
static final int N = 47500;

public static void main(String args[]) {

// создать строку при помощи оператора +

MyTimer mt = new MyTimer();
String str1 =
"";
for (int i = 1; i <= N; i++) {
str1 = str1 + "*";
}
System.out.println("elapsed time #1 = " + mt.getElapsed());

// создать строку при помощи StringBuffer

mt = new MyTimer();
StringBuffer sb =
new StringBuffer();
for (int i = 1; i <= N; i++) {
sb.append("*");
}
String str2 = sb.toString();
System.out.println
("elapsed time #2 = " + mt.getElapsed());

// проверка на равенство

if (!str1.equals(str2)) {
System.out.println("str1/str2 mismatch");
}
}
}

После выполнения этой программы вы должны получить примерно следующий результат:

elapsed time #1 = 61890
elapsed time #2 = 16

Подход №2 явно использует StringBuffer, тогда как подход №1 использует его неявно, как часть реализации оператора +. Вы можете исследовать байт-коды, использующиеся для реализации первого подхода при помощи команды:

javap -c -classpath . AppDemo1

Разница в "+" и StringBuffer

Откуда такая огромная разница между этими двумя подходами? Во втором подходе символы добавляются в StringBuffer, что довольно эффективно. А в первом подходе не используется этот метод? На самом деле нет. Выражение:

str1 = str1 + "*";

не добавляет символы к строке str1. Это происходит из-за того, что Java-строки постоянны, они не изменяются после создания. Вот что происходит в действительности:

  • StringBuffer создается

  • str1 копируется в него

  • "*" добавляется в буфер

  • Результат преобразуется в строку

  • Ссылка str1 меняется для указания на эту строку

  • Старая строка, на которую ранее ссылалась переменная str1, делается доступной для сборщика мусора.

Цикл проходит через N итераций, и на каждой итерации содержимое str1 (содержащей N-1 символов) должно быть скопировано в буфер. Такое поведение подразумевает, что первый подход имеет квадратичную или худшую производительность. "Квадратичная" означает, что время выполнения пропорционально квадрату N. Есть вероятность эффективно заморозить приложение при применении такого типа цикла.

В примере AppDemo1 демонстрируется ситуация, когда периодически присоединяется одна строка к другой, так что обе строки должны быть скопированы во временную область (StringBuffer), создана новая строка и, затем, ссылка на оригинальную строку заменяется ссылкой на новую строку.

Но что если вы не выполняете этот тип операции, а вместо этого, просто имеете некоторый код, похожий на следующий:

public String toString() {
return "X=" + x + " Y=" + y;
}

Здесь нет цикла или повторений и нет строки, которая становится все длиннее и длиннее. Есть какой-либо вред от применения + вместо StringBuffer в этом примере?

Поясняющий пример

В примере AppDemo1 демонстрируется ситуация, когда периодически присоединяется одна строка к другой, так что обе строки должны быть скопированы во временную область (StringBuffer), создана новая строка и, затем, ссылка на оригинальную строку заменяется ссылкой на новую строку.

Но что если вы не выполняете этот тип операции, а вместо этого, просто имеете некоторый код, похожий на следующий:

public String toString() {
return "X=" + x + " Y=" + y;
}

Здесь нет цикла или повторений и нет строки, которая становится все длиннее и длиннее. Есть какой-либо вред от применения + вместо StringBuffer в этом примере?

Для ответа на этот вопрос рассмотрим дополнительный код:

class MyPoint {
private final int x, y;
private final String cache;

public MyPoint(int x, int y) {
this.x = x;
this.y = y;
cache =
"X=" + x + " Y=" + y;
}

public String toString1() {
return "X=" + x + " Y=" + y;
}

public String toString2() {
StringBuffer sb = new StringBuffer();
sb.append
("X=");
sb.append
(x);
sb.append
(" Y=");
sb.append
(y);
return sb.toString();
}

public String toString3() {
String s = "";
s = s +
"X=";
s = s + x;
s = s +
" Y=";
s = s + y;
return s;
}

public String toString4() {
return cache;
}
}

class MyTimer {
private final long start;

public MyTimer() {
start = System.currentTimeMillis();
}

public long getElapsed() {
return System.currentTimeMillis() - start;
}
}

public class AppDemo2 {
static final int N = 1000000;

public static void main(String args[]) {
MyPoint mp = new MyPoint(37, 47);
String s1 =
null;
String s2 =
null;
String s3 =
null;
String s4 =
null;

// toString1

MyTimer mt = new MyTimer();
for (int i = 1; i <= N; i++) {
s1 = mp.toString1();
}
System.out.println("toString1 " + mt.getElapsed());

// toString2

mt = new MyTimer();
for (int i = 1; i <= N; i++) {
s2 = mp.toString2();
}
System.out.println("toString2 " + mt.getElapsed());

// toString3

mt = new MyTimer();
for (int i = 1; i <= N; i++) {
s3 = mp.toString3();
}
System.out.println("toString3 " + mt.getElapsed());

// toString4

mt = new MyTimer();
for (int i = 1; i <= N; i++) {
s4 = mp.toString4();
}
System.out.println("toString4 " + mt.getElapsed());

// проверка исправности для того, чтобы убедиться,
// что результаты, возвращенные из каждого метода toString идентичны

if (!s1.equals(s2) || !s2.equals(s3) || !s3.equals(s4)) {
System.out.println("check error");
}
}
}

В этой программе создается класс MyPoint, который используется для представления точек X,Y. В ней реализуются различные методы toString для класса. Результат выполнения программы может выглядеть примерно так:

toString1 2797
toString2 2703
toString3 5656
toString4 32

Расшифровка результатов

Первые два способа, использующие + и StringBuffer, имеют примерно одинаковую производительность. Поэтому вы можете сделать вывод, что эти два способа фактически идентичны. Генерируемый для toString1 байт-код указывает, что создается StringBuffer, а затем различные строки просто добавляются к нему. Полученный код очень похож на toString2.

Но не все так просто. Первая проблема в том, что вы не всегда сможете сформулировать возвращаемое из toString значение в виде отдельного выражения. toString3 и toString1 показывают идентичные результаты. Но время работы toString3 в два раза больше по причине, описанной в примере AppDemo1. Пример AppDemo2 демонстрирует ситуацию, когда надо создать возвращаемое значение за один раз. В этом случае toString2, использующий явно StringBuffer, является более хорошим выбором.

Другая проблема касается высказывания, найденного в "Спецификации по языку программирования Java" в разделе 15.18.1.2, в котором говорится:

Реализация может выполнить преобразование и конкатенацию за один шаг, чтобы избежать создания и удаления промежуточного объекта String. Для увеличения производительности повторных конкатенаций строки компилятор Java может использовать класс StringBuffer или аналогичную технику для уменьшения количества промежуточных объектов String, создающихся при вычислении выражения.

Это утверждение говорит о том, что компилятор Java не обязательно оптимизирует такое выражение как:

str1 + str2 + str3 + ...

как это сделано для метода toString1, а может вместо этого создать промежуточные строковые объекты.

Поэтому будьте осторожны при использовании оператора +, особенно для длинных строк или в циклах.

Отметим, что существует даже более быстрый способ реализации toString для этого примера. MyPoint является постоянным классом. Это означает, что его экземпляры не могут быть модифицированы после создания. Учитывая это, возвращаемое из toString значение всегда будет одним и тем же. Поскольку значения одинаковы, оно может быть вычислено один раз в конструкторе MyPoint и затем просто возвращено из toString4.

Такой вид кэширования часто очень полезен, но есть и отрицательные стороны. Если класс является изменяемым, то кэширование может не иметь смысла. Тоже самое можно сказать и для ситуаций, когда вычисление значения кэша трудоемко, когда кэш занимает много памяти, или когда метод toString вызывается нечасто.

Ссылки

Дополнительная информация по этой теме находится в разделе 15.18.1 "Оператор конкатенации строк +" в "Спецификации по языку программирования Java, второе издание (http://java.sun.com/docs/books/jls/), и в разделе 5 "Строки" книги "Настройка производительности Java" Jack Shirazi.

Теги: javaProductivitystring

Еще от автора

Применение WeakHashmap для списков слушателей

В статье от 11мая 1999 года Reference Objects были описаны основные идеи применения ссылочных объектов, но не приводилось детального описания. Данная статья позволит вам получить больше сведений, касающихся данной темы. В основном ссылочные объекты применяются для косвенных ссылок на память необходимую объектам. Ссылочные объекты хранятся в очереди (класс ReferenceQueue), в которой отслеживается доступность ссылочных объектов. Исходя из типа ссылочного объекта, сборщик мусора может освобождать память даже тогда, когда обычные ссылки не могут быть освобождены.

Заставки в Mustang

Согласно определению, данному в Wikipedia, заставка - это компьютерный термин, обозначающий рисунок, появляющийся во время загрузки программы или операционной системы. Заставка для пользователя является визуальным отображением инициализации программы. До выхода версии Java SE 6 (кодовое название Mustang) единственной возможностью применения заставки было создание окна, во время запуска метода main, и размещение в нем картинки. Хотя данный способ и работал, но он требовал полной инициализации исполняемой Java среды до появления окна заставки. При инициализации загружались библиотеки AWT и Swing, таким образом, появление заставки задерживалось. В Mustang появился новый аргумент командной строки, значительно облегчающий использование заставок. Этот способ позволяет выводить заставку значительно быстрее до запуска исполняемой Java среды. Окончательное добавление данной функциональности находится на рассмотрении в JCP.

Анонимные классы

1 Введение 2 Типичный пример применения 3 Сортировка списка с использованием анонимных классов 4 Примеры использования 5 Ссылки

Еще по теме

Гибкое журналирование с помощью log4j

Log4j – это инструмент для журналирования с открытым исходным кодом, разработанный под эгидой глобального проекта Jakarta Apache. Он представляет собой набор API с помощью которых, разработчики могут вставлять в свой код выражения, которые выводят некоторую информацию (отладочную, информационную, сообщения об ошибках и т.д.), и конфигурировать этот вывод с помощью внешний конфигурационных файлов. В этой статье рассматриваются основные идеи, положенные в данный инструмент, а также будут затронуты некоторые интересные моменты, касающиеся написания демонстрационного web-приложения.

Аннотации в Java (java annotation types). Пример 1

Продолжаю серию статей о нововведениях в Java (начиная с версии 1.5). На этот раз разговор пойдет об аннотациях (annotation type).

Указатели и виртуальные функции в Java

В настоящее время в Интернете можно найти множество статей как о перспективности платформы Java, так и об её ограниченности. Многих программистов, только присматривающихся к Яве, могут отпугнуть частые заявления, типа: «низкое быстродействие», «отсутствие указателей» и т.д.

Блокировки

Одной из популярных функциональных возможностей библиотек J2SE 5.0 является добавление средств обеспечения параллельной работы. Предоставленные как часть JSR 166 эти средства обеспечивают развитые возможности программирования параллельных процессов, устраняющие необходимость использования разработчиками ключевого слова synchronized и связанных с ним блокировок. Среди предлагаемых ими функциональных возможностей присутствуют: поддержка блокировочных таймаутов, множественные переменные условия для одной блокировки, блокировки чтения/записи и способность прерывать поток, ожидающий снятия блокировки. Более подробную информацию по дополнительной поддержке блокировок можно найти в документации по пакету java.util.concurrent.locks.