Комментарии 11
Не знаю что они изменили в JDK 9, но тесты куска кода
Что в 8 что в 11 работают одинаково медленно и жрут очень много памяти. То что немного убыстрили в 11 — это есть и в основном связано что в JDK9 сделали хранение строк либо в байтах (если ASCII строка) либо в символах (для строк в других кодировках). Если проводить тест с ASCII символами, то памяти меньше расходуется, если с русскими — то так же как и в JDK8
String message = "Hello";
for (int i=0; i<25; i++)
{
message += i;
}
out.println(message);
Что в 8 что в 11 работают одинаково медленно и жрут очень много памяти. То что немного убыстрили в 11 — это есть и в основном связано что в JDK9 сделали хранение строк либо в байтах (если ASCII строка) либо в символах (для строк в других кодировках). Если проводить тест с ASCII символами, то памяти меньше расходуется, если с русскими — то так же как и в JDK8
-2
Как вы измеряли сторость и потребление памяти?
0
Классически: System.currentTimeMillis() и через Runtime.
-2
Такие тесты без применения JMH кажутся странными.
+1
Почему? javap дает более точный результат чем реальное выполнение циклов?
В чем подвох? Неправильно работают внутренние процедуры/функции Java?
В чем подвох? Неправильно работают внутренние процедуры/функции Java?
0
Подвов в методике проведения микробенчмарков.
Что реально даст подобное измерение на цикле в 25 итераций?
Посмотрите доклады Шепелева про методики оценки производительности кода.
Что реально даст подобное измерение на цикле в 25 итераций?
Посмотрите доклады Шепелева про методики оценки производительности кода.
-1
Ну если мне ловить микросекунды, то да, наверное не правильный метод. Но если я запускаю цикл в 10 тысяч итераций, то этот метод нормально отображает неправильность поведения JVM при работе со строками. Мне не нужна точность, мне нужен показатель, что так делать нельзя.
В нормальном профилировании кода, все равно видно что где ты накосячил. А для показа, так делать нельзя, классический тупой подход подходит.
Просто в статье приводится пример что работает через StringBuffer, а в JDK 11 через какую то другую хрень, то я лично не увидел, что в JDK 11 это сработает быстрее.
Но вот классический пример с конкатенацией в цикле и с использованием StringBuilder наглядно показывает, что в JDK8 что в JDK11 лучше использовать StringBuilder в цикле, чем конкатенацию через "+" либо String.concat().
И ничего не поменялось в JDK11, и это видно из статьи. Да на микросекунду стало быстрей!
В нормальном профилировании кода, все равно видно что где ты накосячил. А для показа, так делать нельзя, классический тупой подход подходит.
Просто в статье приводится пример что работает через StringBuffer, а в JDK 11 через какую то другую хрень, то я лично не увидел, что в JDK 11 это сработает быстрее.
Но вот классический пример с конкатенацией в цикле и с использованием StringBuilder наглядно показывает, что в JDK8 что в JDK11 лучше использовать StringBuilder в цикле, чем конкатенацию через "+" либо String.concat().
И ничего не поменялось в JDK11, и это видно из статьи. Да на микросекунду стало быстрей!
-1
Смотря на то, как автор оригинала умудрился скомкать вывод javap
, а в примерах с invokedynamic
блок BootstrapMethods
и вовсе потерять, крепнет уверенность в том, что эта статья не стоила сил, затраченных на перевод.
Для понимания вопроса гораздо полезнее посмотреть старенький доклад Шипилёва, на который есть ссылка в самом первом комментарии.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JDK 9/JEP 280: конкатенация строк никогда больше не будет прежней