生产代码中是否可以使用秒表？
我需要一个准确的计时器，DateTime.Now似乎不够准确。 从我读的说明，System.Diagnostics.Stopwatch似乎正是我想要的。
但是我有恐惧症 我很担心在实际生产代码中使用System.Diagnostics中的任何内容。 （我广泛使用Asserts和PrintLns等debugging，但从来没有生产的东西。）我不只是试图用一个计时器来衡量我的function – 我的应用程序需要一个实际的计时器。 我读过另一个论坛，System.Diagnostics.StopWatch只是基准，不应该用于零售代码，虽然没有任何理由。 这是正确的，还是我（和谁发布的build议）是太closures了System.Diagnostics的头脑？ 即在生产代码中使用System.Diagnostics.Stopwatch是否可行？ 谢谢阿德里安
在引擎盖下，几乎所有的Stopwatch都包装了QueryPerformanceCounter 。 据我所知，Stopwatch在那里提供访问高分辨率计时器 – 如果你需要在生产代码中的这个分辨率，我没有看到使用它的任何错误。
是的， System.Diagnostics听起来只是用于debugging，但不要让名字欺骗你。 System.Diagnostics命名空间可能听起来有点吓人，用于生产代码（它对我来说），但是在这个命名空间中有很多有用的东西。
有些东西，比如Process类，对于与系统交互很有用。 使用Process.Start您可以启动其他应用程序，为用户启动网站，打开文件或文件夹等。
其他的东西，比如Trace类，可以帮助你追踪生产代码中的错误。 当然，你并不总是在生产代码中使用它们，但是它们对于logging和追踪远程机器上难以捉摸的bug 非常有用。
不要担心这个名字。
你说你已经读过另一个论坛，不要在生产中使用System.Diagnostics中的类。 但是唯一值得担心的是创build代码的微软。 他们说StopWatch类 ：
提供一组方法和属性，您可以使用这些方法和属性精确测量已用时间。
他们没有说“除了生产”。
Afaik StopWatch是QueryPerformanceCounterfunction上的一个shell。 这个function是很多性能计数器相关测量的基础。 QPF的通话速度非常快，非常安全。 如果您觉得诊断命名空间偏执，请直接调用QPF。
秒表基本上是原生的QueryPerformanceCounter和QueryPerformanceFrequency方法的一个整洁的包装 。 如果使用System.Diagnostic命名空间感觉不舒服，可以直接访问它们 。
使用性能计数器是非常普遍的，这没有什么错。 AFAIK，没有更高的定时器精度可用。 请注意，QPF可能会导致多处理器机器出现问题 ，但之前链接的MSDN文章提供了一些关于此的附加信息。 build议确保System.Diagnostics.Stopwatch在后台执行此操作，或者手动调用SetThreadAffinity ，否则您的计时器可能会及时跳回 ！
请注意，对于非常高精度的测量，需要考虑一些细微之处 。 如果你需要这么精确的话，这可能是一些问题。
在.NET基类库中有几个不同的计时器类 – 哪一个最适合您的需求只能由您决定。
下面是关于这个主题的MSDN杂志的一篇很好的文章（比较.NET Framework类库中的Timer类）。
根据你使用的计时器，你可能有其他问题需要考虑。 Windows不提供对执行时间的保证，所以你不应该依赖它进行任何实时处理（你可以获得Windows的实时扩展，提供硬实时调度）。 我还怀疑，在捕获时间间隔之后，在您根据其精度进行操作之前，您可能会由于上下文切换而失去精度。 原则上这可能是一段任意长的时间， 在实践中它应该在毫秒量级。 这真的取决于这个时机如何关键。
