JDK 11 против производительности JDK 13 - PullRequest
Новая
       70

JDK 11 против производительности JDK 13

6 голосов
/ 10 февраля 2020

ОБНОВЛЕНИЕ

Из комментариев выяснилось, что выбранный мной подход к тесту был неверным, поэтому результаты вводили в заблуждение. После исправления моего подхода (как в принятом ответе) результаты будут такими, как можно было ожидать - производительность JDK 13 такая же, как и с JDK 11. Более подробные сведения см. В ответе.

Оригинальный вопрос

Я выполнял некоторые тесты производительности на HashSet в Windows 10, используя следующий тестовый код для JMH: 

@Benchmark
@BenchmarkMode(Mode.AverageTime)
@Fork(value = 1, warmups = 1)
public void init() {
    HashSet<String> s = new HashSet<>();
    for (int i = 0; i < 1000000; i++) {
        s.add(Math.random() + "");
    }
    s.size();
}

Я скомпилировал и запустил его под разными версиями JDK, и вот каковы результаты Я получил:

enter image description here

Я также протестировал его с разными размерами кучи (таким образом, 3 разных цвета для каждого JDK). JDK 14 - это, конечно, предварительный снимок с сегодняшнего дня - просто чтобы увидеть, как ZG C работает под Windows.

Интересно - что случилось после JDK 11? (обратите внимание, что для JDK 12 он уже начинает расти, хотя его нет на графике выше)

1 Ответ

1 голос
/ 11 февраля 2020

Спасибо всем за предложения в комментариях.

Ответ, скорее всего, Math.random() или HashSet, или отсутствует Blackhole::consume или их комбинация. Я изменил тест, чтобы просто выполнить i + "aaaaaaaaa" и заменил HashSet на ArrayList, предварительно инициализированный с соответствующим размером, чтобы приспособиться для всех значений, которые будут заполнены. Я также добавил Blackhole::consume в конце, чтобы исключить нежелательную оптимизацию JIT.

После всего этого время постепенно падает с JDK 8 до 11, а затем остается примерно таким же среди JDK 11-13. В JDK 14 он немного повышается, но хорошо - он еще не выпущен.

...