运行计时器对象1000秒的性能损失

尽管论坛的反应，但答案是非常重要的!!

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

简而言之，当你使用Observable时，你实际上并没有创建Timer对象。间隔，实际发生的是有效的-然而，精确的行为是相当复杂的，值得理解。

编辑:在Rx论坛上的一个反诉之后，我对此做了一些详细的分析。在这里查看更全面的讨论:http://social.msdn.microsoft.com/Forums/en-US/rx/thread/13227561-deaa-4984-a52e-601b8a9f8e14

短版本-当到期时间为<</p>

我在响应式论坛上问了这个问题——听起来这样做是100%没问题的。这就是答案

这里引用一下，答案是:

在内存中，只有一个线程处理计时，并且只有一个优先级堆跟踪所有计划的可观察对象。它的可扩展性非常好。因此，即使有成千上万的Observable.Interval查询，您也只有一个实际的计时器和一个实际的线程来管理它。

请不要。最好添加一个带有过期时间戳的列表，并使用一个线程来处理列表。

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

同样，如果同时启动太多线程，您将通过上下文切换获得大量开销，因此处理程序将运行缓慢，这既来自开销，也来自如此多的线程需要分配CPU时间。

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