.NET 秒表类限制
这可能不是一个完全不与 .NET 相关的问题。 我正在编写一个 .NET 应用程序来控制一些小工具。 我定期向小工具发送命令（例如每 500 毫秒）。 一旦我发送命令，我就会启动计时器。 （.NET 秒表类）
如果小工具在 10 毫秒内没有响应，我会再次发送命令。 如果它确实响应，我会通过发送更多命令并处理响应来继续监视小工具状态。
我有 2 或 3 个并行运行的秒表定时器来为这个小工具做其他事情。
现在，我想监视和控制可能有数千个这样的小工具（可能多达 5000 个）。 如果我为一个小工具创建一个对象，我将查看并行运行的 10000 到 15000 个秒表对象。 我不确定秒表是如何工作的，但我认为它们依靠硬件计时器或类似的东西来跟踪时间。
我的问题是，windows可以同时处理这么大量的秒表吗？
This may not be an entirely not a .NET related question.
I am writing a .NET application to control some gadgets. I send commands to the gadget periodically (say every 500 milliseconds). As soon as I send the command I start a timer. (.NET stopwatch class)
If the gadget not respond within say, 10 milliseconds, I send the command again. If it does respond, I continue to monitor the gadget status by sending more commands and processing the responses.
I have 2 or 3 stopwatch timers running in parallel to do other things for this one gadget.
Now, I want to monitor and control potentially thousands of these gadgets (could be as high as 5000). If I create one object for a gadget, I will looking at 10000 to 15000 stopwatch objects running in parallel. I am not sure how the stopwatches work but I assume they rely on a hardware timer or some such thing to keep track of time.
My question is, can windows handle such a large number of stopwatches simultaneously?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我建议重新考虑这个设计。 首先，秒表就像它所说的那样——它就像秒表一样。 如果您希望事件以特定的时间间隔触发，您将需要查看各种 Timer 类。
话虽这么说，我建议在这些小工具之间共享您的计时器。 您会发现，如果您创建的单个调度程序使用的计时器较少，并且调度程序管理小工具，那么一切都会执行得更好，并且可能更容易编写和理解。
I would recommend rethinking this design. First off, Stopwatch just does what it says - it acts like a stopwatch. If you want an event to fire at specific intervals, you'll want to look at the various Timer classes.
That being said, I would recommend sharing your Timers across the gadgets. You will find that everything performs much better, and is probably simpler to write and comprehend if you have fewer timers which are used by a single scheduler you create, and the scheduler manages the gadgets.
秒表只不过是一个保存 Windows API 调用
QueryPerformanceCounter()结果的变量，它在“运行”时没有任何开销。 停止它会再次调用 QueryPerformanceCounter()，因此性能应该没问题。 也就是说，我同意 Reed Copsey 的观点，你需要重新考虑你的设计。 面对如此大量的小工具，我开始考虑设备驱动程序。A stopwatch is nothing but a variable holding the result of Windows API call
QueryPerformanceCounter(), it has no overhead while it's "running". Stopping it callsQueryPerformanceCounter()once more, so performance should be okay. That said, I agree with Reed Copsey, you need to rethink your design. With such a large number of gadgets, I'd start thinking about a device driver.我认为问题应该是你是否可以处理很多计时器； 您将浪费大量时间来阅读数千个计时器而不执行任何功能。
我不知道 Stopwatch 类背后的实现，但我可以想象它们只是在启动和停止时读取计时器的值。 因此，秒表实例可能几乎不需要任何资源。
但只要尝试一下即可； 在循环中生成一个包含数千个实例的数组，启动它们，然后看看会发生什么。
I think the question should be if you can handle some many timers; you will waste much time just reading thousands of timers and doing no functionality.
I am not aware of the implementation behind the Stopwatch class, but I can imagine that they just read the value of a timer on start and on stop again. So a Stopwatch instance might need allmost no resources.
But just try it out; generate an array of some thousend instances in a loop, start them, and look what happens.
想一想保存小工具响应的全局队列以及一个或几个查询队列并在需要时重新发送消息的线程。 它会表现得更好。
Think of global queue which holds gadgets responses and one or a few threads that query the queue and resents messages if needed. It would perform better.
使用一个时间源以指定的时间间隔安排事件
use one time source to schedule events at specified intervals
秒表类非常简单。 它不是一直“运行”的东西。 当你告诉它启动时，它会查看系统时间，而当你告诉它暂停、停止、重置等时，它只会在每次执行此操作时查看系统时间。 询问 ElapsedMilliseconds 相当于说 (Processor.CurrentTicks - StartTicks) / TicksPerMillisecond。 这真的很简单。 系统可以处理大量此类内容。
我不是评论这是否是适合您问题的正确设计，只是回答您的问题：系统可以毫无问题地处理数千个秒表。
The stopwatch class is pretty simple. It's not something that "runs" all the time. When you tell it to start, it looks at the system time, and when you tell it to pause, stop, reset, etc is just looks at the system time each time you do this. Asking the ElapsedMilliseconds is equivalent to saying (Processor.CurrentTicks - StartTicks) / TicksPerMillisecond. It's pretty simple, really. The system can handle a very large number of these.
I'm not commenting on whether or not this is the right design for your problem, just answering your question: the system can handle thousands of stopwatches with no problem.