String.format() в 3 раза быстрее в Java 17

Аннотация: Одним из самых удобных способов построения сложных строк является 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». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.