Как мне написать правильный микро-тест в Java?

Я знаю, что этот вопрос был отмечен как ответ, но я хотел упомянуть две библиотеки, которые позволяют нам писать микро-тесты

Суппорт с Google

Начальные учебные пособия

1. http://codingjunkie.net/micro-benchmarking-with-caliper/
2. http://vertexlabs.co.uk/blog/caliper

JMH из OpenJDK

Начальные учебные пособия

1. Избегание ошибок при тестировании на JVM
2. http://nitschinger.at/Using-JMH-for-Java-Microbenchmarking
3. http://java-performance.info/jmh/

Важными вещами для тестов Java являются:

• Сначала разогрейте JIT, запустив код несколько раз, прежде чем синхронизировать его.
• Убедитесь, что вы запустили его достаточно долго, чтобы иметь возможность измерять результаты в секундах или (лучше) десятки секунд.
• Пока вы не можете вызвать System.gc() между итерациями, неплохо запустить его между тестами, чтобы каждый тест, надеюсь, получил "чистую" память для работы. (Да, gc() - скорее намек, чем гарантия, но очень вероятно, что он действительно будет собирать мусор в моем опыте.)
• Мне нравится показывать итерации и время, а также счет времени/итерации, который можно масштабировать таким образом, чтобы "лучший" алгоритм получал оценку 1.0, а другие оценивались относительным образом. Это означает, что вы можете запускать все алгоритмы в течение длительного времени, изменяя как количество итераций, так и время, но все же получая сопоставимые результаты.

Я как раз в процессе ведения блога о дизайне платформы сравнения в .NET. У меня есть пара более ранние сообщения, которые могут быть способный дать вам некоторые идеи - не все будет уместно, конечно, но некоторые из них могут быть.

jmh является недавним дополнением к OpenJDK и был написан некоторыми инженерами-производителями из Oracle. Конечно, стоит посмотреть.

jmh - это жгутик Java для построения, запуска и анализа тестов nano/micro/macro, написанных на Java и других языках, предназначенных для JVM.

Очень интересные фрагменты информации, похороненные в примеры ответов на тесты.

См. также:

• Предотвращение ошибок в JVM.
• Обсуждение основных сильных сторон jmh.

Если контрольная точка измеряет время/итерацию или итерации/время и почему?

Это зависит от того, что вы пытаетесь проверить. Если вы заинтересованы в задержке, используйте время/итерацию, и если вы заинтересованы в пропускной способности, используйте итерации/время.

Убедитесь, что вы каким-то образом используете результаты, которые вычисляются в контрольном коде. В противном случае ваш код можно будет оптимизировать.

Есть много возможных ошибок для написания микро-тестов в Java.

Во-первых: вам нужно рассчитать всевозможные события, которые занимают время более или менее случайным образом: сбор мусора, эффекты кеширования (ОС для файлов и процессора для памяти), IO и т.д.

Второе: вы не можете доверять точности измеренных времен для очень коротких интервалов.

В-третьих: JVM оптимизирует ваш код во время выполнения. Таким образом, разные прогоны в одном JVM-экземпляре будут быстрее и быстрее.

Мои рекомендации. Сделайте контрольный тест за несколько секунд, что более надежно, чем время выполнения за миллисекунды. Разогрейте JVM (это означает, что хотя бы один раз тестируйте бенчмарк без измерения, JVM может запускать оптимизацию). И запустите свой тест несколько раз (может быть, 5 раз) и возьмите медианную ценность. Запуск каждого микро-теста в новом JVM-экземпляре (вызов для каждого теста новой Java), в противном случае эффекты оптимизации JVM могут повлиять на последующие тесты. Не выполняйте действия, которые не выполняются в фазе прогрева (поскольку это может вызвать загрузку классов и перекомпиляцию).

Если вы пытаетесь сравнить два алгоритма, сделайте по крайней мере два теста на каждом, чередуя порядок. то есть:.

for(i=1..n)
  alg1();
for(i=1..n)
  alg2();
for(i=1..n)
  alg2();
for(i=1..n)
  alg1();

Я обнаружил некоторые заметные различия (иногда 5-10%) во время выполнения одного и того же алгоритма в разных проходах.

Кроме того, убедитесь, что n очень велико, так что время выполнения каждого цикла составляет как минимум 10 секунд или около того. Чем больше итераций, тем более значимые цифры в вашем контрольном времени и более надежные данные.

Следует также отметить, что также может быть важно проанализировать результаты микро-теста при сравнении различных реализаций. Поэтому следует сделать <значимый тест .

Это связано с тем, что реализация A может быть быстрее во время большинства этапов теста, чем реализация B. Но A может также иметь более высокий разброс, поэтому измеренное преимущество производительности A не будет иметь никакого значения по сравнению с B.

Таким образом, также важно правильно записать и запустить микро-тест, а также правильно проанализировать его.

http://opt.sourceforge.net/ Java Micro Benchmark - контроль задач, необходимых для определения сравнительных характеристик производительности компьютерной системы на разных платформах. Может использоваться для управления решениями по оптимизации и для сравнения различных реализаций Java.

Чтобы добавить к другому отличному совету, я также помню следующее:

Для некоторых процессоров (например, Intel Core i5 с TurboBoost) температура (и количество используемых в настоящее время сердечников, а также процент использования) влияет на тактовую частоту. Поскольку процессоры динамически синхронизируются, это может повлиять на ваши результаты. Например, если у вас однопоточное приложение, максимальная тактовая частота (с TurboBoost) выше, чем для приложения, использующего все ядра. Таким образом, это может помешать сравнению одно- и многопоточной производительности на некоторых системах. Имейте в виду, что температура и колебания также влияют на продолжительность поддерживаемой частоты Turbo.

Возможно, более принципиально важный аспект, который у вас есть прямой контроль: убедитесь, что вы правильно оцениваете! Например, если вы используете System.nanoTime() для тестирования определенного бита кода, поместите вызовы в задание в местах, которые имеют смысл избегать измерения того, что вас не интересует. Например, не делайте:

long startTime = System.nanoTime();
//code here...
System.out.println("Code took "+(System.nanoTime()-startTime)+"nano seconds");

Проблема заключается в том, что вы не получаете окончательное время окончания кода. Вместо этого попробуйте следующее:

final long endTime, startTime = System.nanoTime();
//code here...
endTime = System.nanoTime();
System.out.println("Code took "+(endTime-startTime)+"nano seconds");