Используйте лучший счетчик, доступный на вашей платформе, используйте портативность во времени ().
Я использую QueryPerformanceCounter, но вижу комментарии в другом ответе.
Общие советы:
Внутренний цикл должен работать как минимум примерно в 20 раз быстрее, чем разрешение ваших часов, чтобы ошибка разрешения составляла <5%. (поэтому при использовании time () ваш внутренний цикл должен работать не менее 20 секунд) </p>
Повторите эти измерения, чтобы увидеть, соответствуют ли они.
Я использую дополнительный внешний цикл , работающий десять раз и игнорирующий самое быстрое и самое медленное измерение для вычисления среднего и отклонения. Отклонение удобно при сравнении двух реализаций: если у вас один алгоритм, принимающий 2,0 мс +/- 5, а другой 2,2 +/- 0,5, то разница не будет существенной, чтобы назвать одну из них «более быстрой».
(Макс и мин все еще должны отображаться). Так что ИМХО правильное измерение производительности должно выглядеть примерно так:
10000 x 2.0 +/- 0.2 ms (min = 1.2, , max=12.6), 10 repetitions
Если вы знаете, что делаете, очистка кэша и настройка соответствия потоков могут сделать ваши измерения намного более надежными.
Однако это не без пифалов. Чем «стабильнее» измерение, тем менее оно реалистично. Любая реализация будет сильно меняться со временем, в зависимости от состояния данных и кэша команд. Я ленив здесь, используя значение max = для оценки штрафа за первый запуск, этого может быть недостаточно для некоторых сценариев.