Может ли Секундомер использоваться в производственном коде?

Мне нужен точный таймер, а DateTime.Now кажется недостаточно точным. Из описаний, которые я читал, System.Diagnostics.Stopwatch, кажется, именно то, что я хочу.

Но у меня есть фобия. Я нервничаю из-за использования чего-либо из System.Diagnostics в фактическом производственном коде. (Я использую его для отладки с помощью Asserts и PrintLns и т.д., Но еще не для производства.) Я не просто пытаюсь использовать таймер для тестирования моих функций - моему приложению нужен фактический таймер. Я читал на другом форуме, что System.Diagnostics.StopWatch предназначен только для бенчмаркинга и не должен использоваться в розничном коде, хотя причин не было. Правильно ли это, или я (и кто бы ни опубликовал этот совет) был слишком замкнутым в отношении System.Diagnostics? т.е. нормально ли использовать System.Diagnostics.Stopwatch в производственном коде? благодаря Адриан

Ответ 1

Под капотом почти весь Секундомер делает wrap QueryPerformanceCounter. Насколько я понимаю, секундомер предоставляет доступ к таймеру с высоким разрешением - если вам нужно это разрешение в производственном коде, я не вижу ничего плохого в его использовании.

Ответ 2

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

Некоторые вещи, такие как класс Process, полезны для взаимодействия с системой. С помощью Process.Start вы можете запускать другие приложения, запускать веб-сайт для пользователя, открывать файл или папку и т.д.

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

Не беспокойтесь о имени.

Ответ 3

Вы говорите, что читали на другом форуме, чтобы не использовать классы из System.Diagnostics в производстве. Но единственным источником, о котором вы должны беспокоиться, является Microsoft, который создал код. Говорят, что StopWatch класс:

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

Они не говорят "кроме производства".

Ответ 4

Afaik StopWatch - это оболочка поверх функция QueryPerformanceCounter. Эта функция является основой множества измерений, связанных с производительностью. QPF очень быстро звонит и совершенно безопасен. ЕСЛИ вы чувствуете себя параноиком относительно пространства имен Diagnostics, непосредственно pInvoke QPF.

Ответ 5

Секундомер в основном аккуратная обертка вокруг родного QueryPerformanceCounter и QueryPerformanceFrequency. Если вам не удобно пользоваться пространством имен System.Diagnostic, вы можете получить доступ к ним напрямую.

Использование счетчика производительности очень распространено, в этом нет ничего плохого. AFAIK, нет более высокой точности таймера. Обратите внимание, что QPF может привести к <сильным > проблемам с многопроцессорными машинами, но связанная с ним статья MSDN дает дополнительную информацию об этом. Целесообразно убедиться, что System.Diagnostics.Stopwatch делает это в фоновом режиме или вызывает SetThreadAffinity вручную - в противном случае ваш таймер может вернуться назад во времени!

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

Ответ 6

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

Вот хорошая статья из журнала MSDN на эту тему (Сравнение классов таймера в библиотеке классов .NET Framework).

Ответ 7

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