Комментарии 11
В этой же презентации про конкатенацию, кстати, тоже есть. Нельзя бенчмаркать StringBuilder и не упомянуть фичу Хотспота под названием OptimizeStringConcat.
За задачи и разбор +1, но делать выводы о производительности по байткоду не совсем корректно, как я показывал в презентации.
Спасибо!
За исключением тех случаев, когда javac генерирует идентичный байткод. :) В остальном согласен, и чем дальше (тот же JEP-280), тем поведение JIT-компилятора становится менее предсказуемым.
В этой же презентации про конкатенацию, кстати, тоже есть. Нельзя бенчмаркать StringBuilder и не упомянуть фичу Хотспота под названием OptimizeStringConcat.
О, точно, я уже под утро заканчивал статью и про
OptimizeStringConcat
совсем забыл, а это важная штука.Но выбор в пользу первого варианта объяснялся форматом проведения викторины на конференции, когда по ответам можно было быстро отсортировать решения и уже дальше смотреть пояснения к ответам. В следующий раз стоит выбрать детерминированный вариант задач.
И вот тут-то JIT-компилятор может хорошо покуражиться
JIT-то тут при чём? Основную работу делает собственно фабрика, генерируя цепочку методхэндлов, которые сперва считают суммарную длину всех строк, затем выделяют один массив точно нужного размера и всовывают его в строку через небезопасный конструктор.
Да, и ещё то, что с int
типом будет уже не важно, создаётся ли StringBuilder()
с размером по умолчанию или StringBuilder(metrics)
с заранее предопределённым размером. В обоих случаях паттерн new StringBuilder(*).append()...append().toString()
скомпилируется как интринсик без вызова Java кода, и производительность Concatenation vs. StringBuilder будет одинаковая, несмотря на различия в байткоде.
Если же в цепочке попадётся append(long)
, то оптимизация не отработает — ну, не реализовали почему-то в JDK 8), то есть, будет честный вызов Java кода.
OptimizeStringConcat
дописал.Если же в цепочке попадётся append(long), то оптимизация не отработает — ну, не реализовали почему-то в JDK 8), то есть, будет честный вызов Java кода.Судя по изменениям в stringopts.cpp в JDK 10/JDK 9 относительно JDK 8, то в новых версиях это по-прежнему не оптимизируется.
Разбор перформансных задач с JBreak (часть 2)