У меня был более ранний вопрос о интерпретации вывода JMH, на который в основном ответили, но я обновил вопрос другим связанным вопросом, но было бы лучше, чтобы это был отдельный вопрос.
ЭтоОригинальный вопрос: Проверка измерений JMH простых сравнений ля / лямбда .
Мой вопрос касается производительности потоков на определенных уровнях "работы".Следующие отрывочные результаты из предыдущего вопроса иллюстрируют то, о чем я удивляюсь:
Benchmark Mode Cnt Score Error Units
MyBenchmark.shortLengthConstantSizeFor thrpt 200 132278188.475 ± 1132184.820 ops/s
MyBenchmark.shortLengthConstantSizeLambda thrpt 200 18750818.019 ± 171239.562 ops/s
MyBenchmark.mediumLengthConstantSizeFor thrpt 200 55447999.297 ± 277442.812 ops/s
MyBenchmark.mediumLengthConstantSizeLambda thrpt 200 15925281.039 ± 65707.093 ops/s
MyBenchmark.longerLengthConstantSizeFor thrpt 200 3551842.518 ± 42612.744 ops/s
MyBenchmark.longerLengthConstantSizeLambda thrpt 200 2791292.093 ± 12207.302 ops/s
MyBenchmark.longLengthConstantSizeFor thrpt 200 2984.554 ± 57.557 ops/s
MyBenchmark.longLengthConstantSizeLambda thrpt 200 331.741 ± 2.196 ops/s
Я ожидал, поскольку тесты переместились из более коротких списков в более длинные списки, что производительность потокового теста должна приближаться кпроизводительность теста «для».
Я видел, что в «коротком» списке производительность потока составляла 14% от производительности «для».Для среднего списка это было 29%.Для более длинного списка это было 78%.До сих пор эта тенденция была тем, чего я ожидал.Однако для длинного списка это составляет 11%.По какой-то причине размер списка 300 КБ, а не 300, вызвал снижение производительности потока по сравнению с «для».
Мне было интересно, сможет ли кто-нибудь подтвердить подобные результаты, ибыли ли у них какие-либо мысли о том, почему это может происходить.
Я запускаю это на ноутбуке Win7 с Java 8.