Допустимо ли тестирование секундомера?

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

Я не думаю, что тестирование секундомера слишком ужасно, но если вы можете попасть на машину с Solaris или OS X, вам следует проверить DTrace. Я использовал его, чтобы получить отличную информацию о времени в своих приложениях.

Тестирование секундомера в порядке, если вы измеряете итерации достаточно, чтобы быть значимыми. Обычно мне требуется, чтобы общее прошедшее время составляло некоторое количество секунд, состоящих из одной цифры. В противном случае ваши результаты могут быть значительно искажены из-за планирования и других сбоев в работе вашего процесса.

Для этого я использую небольшой набор статических методов, которые я построил много лет назад, которые основаны на System.currentTimeMillis().

Для профилирования я использовал jProfiler в течение нескольких лет и нашел его очень хорошим. Я недавно просмотрел YourKit, который кажется отличным с веб-сайта, но лично я его вообще не использовал.

Чтобы ответить на вопрос о планировании прерываний, я обнаружил, что выполнение повторных запусков до тех пор, пока согласованность не будет достигнута / не будет наблюдаться, на практике помогает отсеять аномальные результаты планирования процессов. Я также считаю, что планирование потоков не имеет практического значения для прогонов от 5 до 30 секунд. Наконец, после того, как вы пройдете несколько секунд, планирование порогового значения, по моему опыту, окажет незначительное влияние на результаты - я обнаружил, что 5-секундный прогон постоянно в среднем дает то же самое, что и 5-минутный прогон для времени / итерации.

Вы также можете подумать о предварительном запуске протестированного кода примерно 10 000 раз, чтобы «разогреть» JIT, в зависимости от того, сколько раз вы ожидаете, что тестируемый код будет выполняться с течением времени в реальной жизни.

Профилировщик предоставляет более подробную информацию, которая может помочь в диагностике и устранении проблем с производительностью.

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

Однако, когда вы действительно хотите исправить проблемы, профилировщик может быть действительно полезен.

Сегодня я запустил программу, которая просматривала и собирала информацию из кучи файлов dBase, для ее выполнения потребовалось чуть больше час. Я взглянул на код, сделал обоснованное предположение, в чем заключалась проблема, немного улучшил алгоритм и повторно запустил программу, на этот раз она завершилась в 2,5 минуты.

Мне не потребовались какие-либо причудливые инструменты профилирования или комплекты тестов, чтобы сказать, что новая версия является значительным улучшением. Если бы мне нужно было дополнительно оптимизировать время работы, я бы, вероятно, провел более сложный анализ, но в этом не было необходимости. Я считаю, что такого рода «бенчмаркинг секундомера» является приемлемым решением во многих случаях, и использование более продвинутых инструментов в этих случаях потребует больше времени.

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

Это полностью справедливо, если вы измеряете достаточно большие интервалы времени. Я бы выполнил 20-30 прогонов того, что вы собираетесь протестировать, чтобы общее затраченное время превысило 1 секунду. Я заметил, что расчет времени на основе System.currentTimeMillis () обычно составляет 0 мс или ~ 30 мс; Я не думаю, что вы можете получить что-то более точное, чем это. Вы можете попробовать System.nanoTime (), если вам действительно нужно измерить небольшой временной интервал:

• документация: http://java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime ()
• ТАК вопрос об измерении малых промежутков времени, поскольку у System.nanoTime () тоже есть некоторые проблемы: Как я могу измерить время с точностью до микросекунд в Java?

В конце концов, это, вероятно, вторая по популярности форма тестирования производительности сразу после «тестирования без наблюдения», когда мы говорим «эта активность кажется медленной, а другая - быстрой».

Обычно наиболее важным для оптимизации является то, что мешает взаимодействию с пользователем, что чаще всего зависит от того, как часто вы выполняете действие, и от того, что еще происходит в то же время. Другие формы сравнительного анализа часто просто помогают сосредоточиться на них.

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

Думаю, ключевой вопрос - это сложность и длительность операции.

Иногда я даже использую физические измерения секундомера, чтобы увидеть, требуется ли что-то для вычисления минут, часов, дней или даже недель (я работаю с приложением, в котором время выполнения порядка нескольких дней не является чем-то неслыханным, даже если секунды и минуты наиболее распространенные промежутки времени).

Однако автоматизация, обеспечиваемая вызовами любой системы часов на компьютере, например вызов java millis, упомянутый в связанной статье, явно превосходит ручную проверку того, как долго что-то работает.

Профилировщики хороши, когда они работают, но у меня возникли проблемы с их применением в нашем приложении, которое обычно включает динамическую генерацию кода, динамическую загрузку библиотек DLL и работу, выполняемую на двух встроенных языках сценариев, скомпилированных точно в срок. мое заявление. Они довольно часто ограничиваются предположением о едином исходном языке и другими нереалистичными ожиданиями в отношении сложного программного обеспечения.

Секундомер на самом деле лучший тест!

Реальное время ответа конечного пользователя - это время, которое действительно имеет значение.

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

Инструменты отлично подходят для автоматического тестирования и определения проблем, но не упускайте из виду то, что вы действительно хотите измерить.

Вам нужно протестировать реалистичное количество итераций, поскольку вы получите разные ответы в зависимости от того, как вы проверяете время. Если вы выполняете операцию только один раз, было бы неверно брать среднее значение многих итераций. Если вы хотите узнать время, необходимое для разогрева JVM, вы можете выполнить много (например, 10 000) итераций, которые не включены в тайминги.

Я также предлагаю вам использовать System.nanoTime(), так как он намного точнее. Если время вашего теста составляет около 10 микросекунд или меньше, вы не хотите вызывать это слишком часто, иначе это может изменить ваш результат. (например, если я тестирую, скажем, 5 секунд и хочу знать, когда это произойдет, я получаю nanoTime только каждые 1000 итераций, если я знаю, что итерация очень быстрая)

How do you address operating system scheduling when benchmarking?

Тест для достаточно длинный в системе, которая является репрезентативной для машины, которую вы будете использовать. Если ваша ОС замедляет работу вашего приложения, это должно быть частью результата.

Нет смысла говорить, что моя программа была бы быстрее, если бы у меня не было ОС.

Если вы используете Linux, вы можете использовать такие инструменты, как numactl, chrt и taskset, чтобы контролировать использование процессоров и планирование.