Ограничения класса секундомера .NET

Question

Возможно, это не совсем вопрос, связанный с .NET. Я пишу .NET-приложение для управления некоторыми гаджетами. Я периодически отправляю команды на гаджет (скажем, каждые 500 миллисекунд). Как только я отправляю команду, я запускаю таймер. (Класс секундомера .NET)

Если гаджет не отвечает в течение, скажем, 10 миллисекунд, я отправляю команду еще раз. Если он отвечает, я продолжаю следить за состоянием гаджета, отправляя дополнительные команды и обрабатывая ответы.

У меня есть 2 или 3 таймера секундомера, которые работают параллельно для выполнения других задач для этого гаджета.

Теперь я хочу отслеживать и контролировать тысячи таких гаджетов (может достигать 5000). Если я создам один объект для гаджета, я буду смотреть от 10000 до 15000 объектов секундомера, работающих параллельно. Я не уверен, как работают секундомеры, но я полагаю, что они используют аппаратный таймер или что-то подобное для отслеживания времени.

У меня вопрос: могут ли окна обрабатывать такое большое количество секундомеров одновременно?

Answer 1

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

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

Answer 2

Секундомер - это не что иное, как переменная, содержащая результат вызова Windows API QueryPerformanceCounter(), у него нет накладных расходов, пока он работает Остановка вызова вызывает QueryPerformanceCounter() еще раз, поэтому производительность должна быть в порядке. Тем не менее, я согласен с Ридом Копси, вам нужно переосмыслить свой дизайн. С таким большим количеством гаджетов я бы начал думать о драйвере устройства.

Answer 3

Класс секундомера довольно прост. Это не то, что "работает" все время. Когда вы говорите, что он запускается, он смотрит на системное время, а когда вы говорите, чтобы он останавливался, останавливался, сбрасывался и т. Д., Просто смотрел на системное время каждый раз, когда вы это делаете. Запрашивать ElapsedMilliseconds эквивалентно высказыванию (Processor.CurrentTicks - StartTicks) / TicksPerMillisecond. Это довольно просто, правда. Система может обрабатывать очень большое количество из них.

Я не комментирую, является ли это подходящим решением для вашей проблемы, просто отвечаю на ваш вопрос: система может обрабатывать тысячи секундомеров без проблем.

Answer 4

использовать один источник времени для планирования событий с заданными интервалами

Answer 5

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

Answer 6

Я думаю, что вопрос должен быть, если вы можете справиться с несколькими таймерами; Вы будете тратить много времени просто на чтение тысяч таймеров и не выполняете никаких функций.

Я не знаю о реализации класса Stopwatch, но могу представить, что они просто читают значение таймера при запуске и при остановке снова. Таким образом, экземпляру секундомера может не потребоваться никаких ресурсов.

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