Секундомер против использования System.DateTime.Now для событий синхронизации
Я хотел отслеживать производительность моего кода, поэтому я сохранил время начала и окончания, используя System.DateTime.Now . Я взял разницу между ними как время моего кода для выполнения.
Я заметил, что разница не была точной. Поэтому я попытался использовать объект Stopwatch . Это оказалось намного точнее.
Может ли кто-нибудь сказать мне, почему Stopwatch будет более точным, чем вычисление разницы между временем начала и окончания с использованием System.DateTime.Now ?
- Строка против StringBuilder
- Что происходит после промаха L2 TLB?
- почему GCC __builtin_prefetch не улучшает производительность?
- Обработка предупреждения для возможного множественного enums IEnumerable
- Тестирование производительности сериализаций, используемых привязками WCF
Кстати, я не говорю о десятых процента. Я получаю разницу в 15-20%.
- Есть ли разница в производительности между Javac debug on и off?
- Установка свойства изображения UIImageView вызывает серьезное отставание
- Как передавать значения на страницах ASP.net без использования сеанса
- Почему XCHG reg, reg 3 инструкции по микрооперации на современных архитектурах Intel?
- Потоки Java 8: почему параллельный stream медленнее?
- C # самый быстрый способ смены массива
- Почему петли медленны в R?
- Производительность mgo-запросов кажется медленно медленной (500-650 мс)
Согласно MSDN :
Секундомер измеряет прошедшее время, подсчитывая отметки таймера в базовом таймерном механизме. Если установленная аппаратная и операционная система поддерживает счетчик производительности с высоким разрешением, то class секундомера использует этот счетчик для измерения прошедшего времени. В противном случае class секундомера использует системный таймер для измерения прошедшего времени. Используйте поля Frequency и IsHighResolution для определения точности и разрешения реализации синхронизации секундомера.
Он использует более высокое разрешение / точность, чем DateTime.Now .
Вы также можете проверить эти связанные ссылки:
Environment.TickCount против DateTime.Now
Является ли DateTime.Now лучшим способом измерения производительности функции?
DateTime достаточно хорош для точности ко второй, возможно, но что-то помимо этого я бы рекомендовал StopWatch .
Лучше использовать class секундомера, потому что он намного точнее, чем вычитание значений DateTime:
Stopwatch s = Stopwatch.StartNew(); // Tested code here s.Stop(); Console.WriteLine("Elapsed Time: {0} ms", s.ElapsedMilliseconds);
К сожалению, этого простого fragmentа кода будет недостаточно, чтобы получить точные измерения в большинстве случаев, потому что под капотом ОС происходит много активности, что может украсть некоторое время процессора и замедлить выполнение вашего кода. Вот почему лучше всего выполнять тесты несколько раз, а затем удалять самые низкие и самые высокие времена. Для этого puprose это хорошее решение, чтобы иметь метод, который выполняет проверенный код несколько раз, удаляет самое низкое и наибольшее время и вычисляет среднее время. Я опубликовал образец метода тестирования в своем блоге .
эта функциональная ссылка для функции синхронизации обсуждает вашу точную проблему, в частности этот параграф:
Проблема в том, что согласно MSDN разрешение функции DateTime.Now составляет 10+ миллисекунд, и нам нужно позвонить ему дважды! Таким образом, это приведет к качанию 20 + ms в вашем измерении времени выполнения. Поскольку наши вызовы функций часто бывают намного быстрее, чем это 20-секундное окно, это не достаточно хорошо.
EDIT: Это похоже на второй DateTime.Now вызывается в другое время, чем когда заканчивается метод секундомера.