Алексей Шипилёв - Java Benchmarking: как два таймстампа прочитать!

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Алексей Шипилёв - Java Benchmarking: как два таймстампа прочитать!
Java-конференция Joker 2014
Санкт-Петербург, 20 - 21 октября 2014
Померить производительность - это так просто! Два раза по System.nanoTime(), взяли разность, сложили-поделили, и всё, можно оптимизировать. Как бы не так!
В этом докладе мы поговорим о том, как исследуют производительность приложений при помощи бенчмарков, какие частые ошибки возникают, как с ними бороться, и как вообще получить хоть какие-то полезные данные о мире, где всё от всего зависит. Красной нитью в докладе проходит Java Microbenchmark Harness (JMH), стандартный инструмент для написания и исследования бенчмарков в OpenJDK.

[@bademusl]

Шеф, забацай RSS на shipilev.net, а то гугль находит только обещания. Хотелось бы под feedly.com подцепить

[@user-on9rp9jj2d]

Ахах) Первое что в голову пришло ответить - "это Java хреново а не Node.js хорошо" ))

[@Alexander-mj3jk]

Насчет того, что он говорит на 45 минуте. Мол, проблема в бенчмаркинге, и мы щас умышленно _затормозим_ жаву подсунув ей рандом на вход, и покажем, что ее немножко обгоняет скала. Кто ему дал право тормозить жаву? Кто дал право подсовывать другие входящие параметры? Скале же на вход приходит тоже константа времени компиляции, а не рандом! Так что, пускай разгоняет скалу, а не тормозит жаву!!! То, что жава увидела константу времени компиляции, а скала не увидела - это показательный момент, который мы не можем проигнорировать! Поэтому, ясное дело, что влияние этого фактора должно быть отражено в тестах. Лично я его тест интерпретировал так: скала не всегда видит то, что можно заоптимайзить, поэтому в среднем работает медленней.

[@alexeiosipov6304]

> Кто дал право подсовывать другие входящие параметры А как еще выполнять проверку гипотез? Только изменяя эксперимент и пробуя другие параметры. И докладчик не говорит что проблема в бенчмаркинге. А в том, что нельзя просто остановиться и сказать, "на нашем тесте Java быстрее, так как на бенчмарке циферка выше". Исходная цель того бенчмарка - оценить производительность метода в нормальных условиях (со произвольными входными данными), а не тогда, когда там константа передается. Именно в том польза от анализа результатов, что удалось выяснить, что наличие константы в этом тесте помогает Java, но не помогает Scala. Речь в докладе идет именно о пользе такого анализа. А кто там быстрее, Java или Scala, это вообще не относится к теме докалада.