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

Question

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

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

Answer 1

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

Answer 2

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

Answer 3

Секундомер basically a neat wrapper вокруг родного QueryPerformanceCounter и QueryPerformanceFrequency методов. Если вы не чувствуете себя комфортно, используя пространство имен System.Diagnostic, вы можете access these directly.

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

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

Answer 4

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

Here is a good article from MSDN magazine on the subject (Comparing the Timer Classes in the .NET Framework Class Library).

Answer 5

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

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

Они не говорят «за исключением производства».

Answer 6

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

Answer 7

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

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

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

Не беспокойтесь о названии.