Аннотация: Одним из самых удобных способов построения сложных строк является String.format(). Раньше он был чрезмерно медленным, но в Java 17 стал примерно в 3 раза быстрее. В данном выпуске мы выясним, в чем разница и где это вам поможет. А также когда следует использовать format() вместо обычного сложения строк с помощью +.

Несколько лет назад мы с моим другом Дмитрием Вязеленко представили доклад на JavaOne, где около часа рассказывали о скромном java.lang.String. С тех пор мы рассказывали об этом основном классе на Devoxx, Geecon, Geekout, JAX, Voxxed Days, GOTO и различных JUG по всему миру. Кто бы мог подумать, что можно легко заполнить час разговором о java.lang.String?

Обычно я начинал выступление с викторины. Какой метод является самым быстрым при добавлении строк?

public class StringAppendingQuiz {
  public String appendPlain(String question,
                            String answer1,
                            String answer2) {
    return "<h1>" + question + "</h1><ol><li>" + answer1 +
        "</li><li>" + answer2 + "</li></ol>";
  }

  public String appendStringBuilder(String question,
                                    String answer1,
                                    String answer2) {
    return new StringBuilder().append("<h1>").append(question)
        .append("</h1><ol><li>").append(answer1)
        .append("</li><li>").append(answer2)
        .append("</li></ol>").toString();
  }

  public String appendStringBuilderSize(String question,
                                        String answer1,
                                        String answer2) {
    int len = 36 + question.length() + answer1.length() +
        answer2.length();
    return new StringBuilder(len).append("<h1>").append(question)
        .append("</h1><ol><li>").append(answer1)
        .append("</li><li>").append(answer2)
        .append("</li></ol>").toString();
  }
}
  

Аудитории предлагается выбрать один из трех вариантов, appendPlain, appendStringBuilder и appendStringBuilderSize. Большинство разрывается между простой (plain) и увеличенной (sized) версией. Но это вопрос с подвохом. Для обычного случая, как сложение простых строк вместе, производительность эквивалентна, независимо от того, используем ли мы обычный + или StringBuilder, с предварительно заданным размером или без него. Однако все меняется, когда мы добавляем смешанные типы, например, некоторые long значения и строки. В этом случае StringBuilder с предварительным размером является самым быстрым до Java 8, а начиная с Java 9 и далее, самым быстрым является обычный +.

Для сравнения, мы показали, что использование String.format во много раз медленнее. Например, в Java 8 правильно подобранный StringBuilder с append (добавлением) выполнялся в 17 раз быстрее, чем аналогичный String.format(), в то время как в Java 11 обычный + был в 39 раз быстрее format(). Несмотря на такие огромные различия, наша рекомендация в конце выступления была следующей:

Конкатенация с помощью String.format()

• Проще для чтения и поддержки.

• Для критической производительности пока используйте +

• В циклах по-прежнему используйте StringBuilder.append().

В некотором смысле это была трудная идея. Зачем программисту сознательно делать то, что в 40 раз медленнее?

Нюанс в том, что инженеры Oracle знали, что String.format() медленный и работали над его улучшением. Мы даже нашли версию Project Amber, которая компилировала код format() с той же скоростью, что и простой оператор +.

После выхода Java 17 я решил заново прогнать все наши предварительные бенчмарки. Сначала мне казалось, что это пустая трата времени. В конце концов, эталоны уже были сделаны. Зачем запускать их снова? Во-первых, машина, которую мы использовали изначально, уже была выведена из эксплуатации, а мне хотелось увидеть последовательные результаты на протяжении всего исследования, запустив все на своей машине для тестирования производительности. С другой стороны, я хотел посмотреть, были ли какие-либо изменения в JVM, которые могли бы повлиять на результаты. Я не предполагал, что последнее станет важным фактором.

Представьте себе мое удивление, когда я заметил, что функция String.format() радикально улучшилась. Вместо 2170 нс/оп в Java 11, теперь она стала выполняться "всего" за 705 нс/оп. Таким образом, вместо того, чтобы быть примерно в 40 раз медленнее, чем обычный +, String.format() оказался всего в 12 раз медленнее. Или, если посмотреть с другой точки зрения, Java 17 String.format() в 3 раза быстрее, чем в Java 16.

Замечательная новость, но при каких обстоятельствах это будет быстрее? Я поделился своим открытием с Дмитрием Вязеленко, и он указал мне на работу Claes Redestad в JDK-8263038 : Оптимизация String.format для простых спецификаторов. Актуальный код доступен в GitHub OpenJDK.

Claes был достаточно любезен, ответив на мой запрос, и подтвердил, что мы можем ожидать более быстрого форматирования для простых спецификаторов. Другими словами, спецификаторы - это знак процента %, за которым следует всего одна буква в диапазоне "bBcCtTfdgGhHaAxXno%eEsS". Если добавляется дополнительное форматирование, например, ширина, точность или выравнивание, тогда, вероятно, это уже не будет быстрее.

Как работает данная чудесная функция? Каждый раз, когда мы вызываем, например, String.format("%s, %d%n", name, age), необходимо сделать парсинг строки "%s, %d%n". Это делается в методе java.util.Formatter#parse(), который использует для парсинга элементов форматирования приведённое ниже регулярное выражение (regex):

// %[argument_index$][flags][width][.precision][t]conversion
private static final String formatSpecifier
    = "%(\\d+\\$)?([-#+ 0,(\\<]*)?(\\d+)?(\\.\\d+)?([tT])?([a-zA-Z%])";

private static final Pattern fsPattern = Pattern.compile(formatSpecifier);

В коде до версии 17 функция parse() всегда начиналась с применения регекса к строке формата (format String). Однако в Java 17 вместо этого мы пытаемся выполнить парсинг строки формата вручную. Если все FormatSpecifiers "простые", то можно обойтись без повторного парсинга. Когда один из них не простой, то парсинг выполняется с этого момента. Это ускоряет парсинг в 3 раза для простых строк формата. Вот тестовая программа, в которой я выполняю парсинг следующих строк:

// should be faster
"1. this does not have any percentages at all"
// should be faster
"2. this %s has only a simple field"
// might be slower
"3. this has a simple field %s and then a complex %-20s"
// no idea
"4. %s %1s %2s %3s %4s %5s %10s %22s"

Мы передаем эти строки приватному методу Formatter#parse с помощью MethodHandles и измеряем, сколько времени это занимает в Java 16 и 17.

С Java 16 мы получили следующие результаты на нашем тестовом сервере:

Best results:
1. this does not have any percentages at all
	137ms
2. this %s has only a simple field
	288ms
3. this has a simple field %s and then a complex %-20s
	487ms
4. %s %1s %2s %3s %4s %5s %10s %22s
	1557ms

Результаты, полученные с Java 17:

Best results:
1. this does not have any percentages at all
	21ms     // 6.5x faster
2. this %s has only a simple field
	32ms     // 9x faster
3. this has a simple field %s and then a complex %-20s
	235ms    // 2x faster
4. %s %1s %2s %3s %4s %5s %10s %22s
	1388ms   // 1.12x faster

Таким образом, можно рассчитывать на существенную разницу при работе со строками формата, имеющими простые поля, что составляет подавляющее большинство случаев. Спасибо Claes Redestad за усилия, приложенные к тому, чтобы сделать это быстрее. Я буду придерживаться своего совета использовать String.format(), или, еще лучше, относительно новый метод formatted(), и пусть разработчики JDK ускорят его для нас.

Вот тестовый код, на случай, если вы захотите попробовать сами. Мы используем следующие параметры JVM: -showversion --add-opens java.base/java.util=ALL-UNNAMED -Xmx12g -Xms12g -XX:+UseParallelGC -XX:+AlwaysPreTouch-verbose:gc

import java.lang.invoke.*;
import java.util.*;
import java.util.concurrent.*;
import java.util.concurrent.atomic.*;

// run with
// -showversion --add-opens java.base/java.util=ALL-UNNAMED
// -Xmx12g -Xms12g -XX:+UseParallelGC -XX:+AlwaysPreTouch
// -verbose:gc
public class MixedAppendParsePerformanceDemo {
  private static final Map<String, LongAccumulator> bestResults =
      new ConcurrentSkipListMap<>();

  public static void main(String... args) {
    String[] formats = {
        // should be faster
        "1. this does not have any percentages at all",
        // should be faster
        "2. this %s has only a simple field",
        // might be slower
        "3. this has a simple field %s and then a complex %-20s",
        // no idea
        "4. %s %1s %2s %3s %4s %5s %10s %22s",
    };

    System.out.println("Warmup:");
    run(formats, 5);
    System.out.println();

    bestResults.clear();

    System.out.println("Run:");
    run(formats, 10);
    System.out.println();

    System.out.println("Best results:");
    bestResults.forEach((format, best) ->
        System.out.printf("%s%n\t%dms%n", format,
            best.longValue()));
  }

  private static void run(String[] formats, int runs) {
    for (int i = 0; i < runs; i++) {
      for (String format : formats) {
        Formatter formatter = new Formatter();
        test(formatter, format);
      }
      System.gc();
      System.out.println();
    }
  }

  private static void test(Formatter formatter, String format) {
    System.out.println(format);
    long time = System.nanoTime();
    try {
      for (int i = 0; i < 1_000_000; i++) {
        parseMH.invoke(formatter, format);
      }
    } catch (Throwable throwable) {
      throw new AssertionError(throwable);
    } finally {
      time = System.nanoTime() - time;
      bestResults.computeIfAbsent(format, key ->
              new LongAccumulator(Long::min, Long.MAX_VALUE))
          .accumulate(time / 1_000_000);
      System.out.printf("\t%dms%n", (time / 1_000_000));
    }
  }

  private static final MethodHandle parseMH;

  static {
    try {
      parseMH = MethodHandles.privateLookupIn(Formatter.class,
              MethodHandles.lookup())
          .findVirtual(Formatter.class, "parse",
              MethodType.methodType(List.class, String.class));
    } catch (ReflectiveOperationException e) {
      throw new Error(e);
    }
  }
}
  

Также существуют и другие хорошие способы повышения производительности в Java 17.

Материал подготовлен в рамках курса «Java Developer. Professional». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.