1000个运行Timer对象的性能损失？

Question

是否存在数千个正在运行的Timer对象的性能考虑因素（通过调用Reactive RX的Observable.Interval扩展方法在后台生成）？这适用于服务器应用程序。可能同时运行的计时器的数量将是数千到数万。

Answer 1

请不要。最好添加到具有到期时间戳的列表并使用f.e.一个处理列表的线程。

Answer 2

我在Reactive论坛上问过这个问题 - 听起来这样做是100％好的。 This is the answer

在这里引用它，答案是：

  

从内存中有一个处理时间的线程，并且有一个优先级堆可以跟踪所有已调度的可观察对象。它非常好地扩展。因此，即使有成千上万的{{​​1}}个查询，您只有一个实际的计时器和一个实际的线程来管理它。

Answer 3

论坛的回应尽管如此，但答案并非如此重要！

我建议你制作一个大一壶咖啡，并在这里阅读Bart de Smet的博客文章：http://blogs.msdn.com/b/rxteam/archive/2012/06/20/reactive-extensions-v2-0-release-candidate-available-now.aspx

简而言之，在使用Observable.Interval时，实际上并没有创建Timer对象，实际发生的事情 有效 - 但是，精确的行为非常复杂，值得理解。

编辑：在对Rx论坛提出反诉后，我对此进行了一些详细的分析。请参阅此处以获得更全面的讨论：http://social.msdn.microsoft.com/Forums/en-US/rx/thread/13227561-deaa-4984-a52e-601b8a9f8e14

简短版本 - 当到期时间<＆lt; 10秒后，否则会使用一个计时器。

Answer 4

您会注意到最明显的事情是可以同时处理的计时器事件的数量受CPU核心数量的限制。如果同时触发太多事件，它们将排队并可能会有相当长的延迟处理。

此外，如果同时启动的线程太多，上下文切换会产生大量开销，因此处理程序运行缓慢，既有开销，也有很多线程需要分配的事实CPU时间。

考虑是否可以运行单个计时器，并让它处理逻辑计时器列表。