Секундомер действительно сломан?

Question

На странице MSDN для Класс секундомера Я обнаружил ссылку на интересную статью , которая делает следующее заявление о секундомере:

Однако есть некоторые серьезные проблемы:

• Это может быть ненадежно на ПК с несколькими процессорами. Из-за ошибки в
  BIOS, Start () и Stop () должны выполняться на одном процессоре, чтобы получить правильный результат.

• Это ненадежно на процессорах, которые не имеют постоянных часов скорость (большинство процессоров может уменьшить тактовую частоту, чтобы сохранить энергия). Это подробно объясняется здесь .

Я немного растерялся. Я видел тонн примеров использования секундомера, и никто не упоминал об этих недостатках. Насколько это серьезно? Стоит ли избегать использования секундомера?

Answer 1

Более интересные вопросы:

1. при каких условиях Stop () будет выполняться на процессоре, отличном от Start ()?
   .
   В большинстве сценариев приложений:ответ "нет".

2. при каких условиях будет изменяться тактовая частота процессора в течение измеренного интервала?
   .
   В тестах, интенсивно использующих процессор, "нет".

Answer 2

См. Примечания в статье MSDN:

На многопроцессорном компьютере не имеет значения, на каком процессоре работает поток. Однако из-за ошибок в BIOS или на уровне аппаратных абстракций (HAL) вы можете получить разные результаты синхронизации на разных процессорах. Чтобы указать привязку процессора к потоку, используйте метод ProcessThread.ProcessorAffinity.

Answer 3

Это не сломано , оно просто имеет ограничения. Для большинства целей (читай: неформальный микро-бенчмаркинг) StopWatch хорошо использовать просто потому, что оно достаточно для неформального тестирования. Для более формальных целей вы, скорее всего, захотите использовать свой собственный код инструментария, так как вы бы потратили гораздо больше на получение правильных результатов.