可以在生产代码中使用秒表吗？

我需要一个准确的计时器，而DateTime.Now似乎不够准确。根据我阅读的说明，System.Diagnostics.Stopwatch似乎正是我想要的。

但是我有恐惧症。我担心在实际生产代码中使用System.Diagnostics中的任何内容。（我将它广泛用于与Asserts和PrintLns等一起进行调试，但从未用于生产方面。）我不仅在尝试使用计时器来对我的函数进行基准测试-我的应用程序需要一个实际的计时器。我在另一个论坛上读到System.Diagnostics.StopWatch仅用于基准测试，尽管没有给出理由，但不应在零售代码中使用。这是正确的，还是我（以及发布此建议的人）对System.Diagnostics过于封闭？即，可以在生产代码中使用System.Diagnostics.Stopwatch吗？谢谢阿德里安

在后台，秒表几乎所有要做的就是包装 QueryPerformanceCounter。据我了解，秒表可用于访问高分辨率计时器-如果您在生产代码中需要此分辨率，则使用它不会有任何问题。

是的，System.Diagnostics听起来好像仅用于调试，但不要让名称欺骗您。的System.Diagnostics起初命名空间在生产代码中使用似乎听起来有些吓人（对我而言确实如此），但是该命名空间中有很多有用的东西。

诸如Process类之类的某些东西对于与系统交互很有用。有了Process.Start你可以启动其他应用程序，推出一个网站用户，打开一个文件或文件夹，等等。

其他诸如Trace类之类的东西可以帮助您跟踪生产代码中的错误。当然，您不会总是在生产代码中使用它们，但是它们对于在远程计算机上记录和跟踪难以捉摸的错误非常有用。

不用担心名字。

您说您在另一个论坛上阅读过，不使用System.Diagnostics生产环境中的类。但是，您唯一需要担心的来源就是创建代码的Microsoft。他们说StopWatch班上：

提供了一组方法和属性，可用于准确测量经过的时间。

他们没有说“生产中除外”。

Afaik StopWatch是QueryPerformanceCounter功能的外壳。此功能是许多性能计数器相关测量的基础。QPF的呼叫速度非常快，而且绝对安全。如果您对Diagnostics名称空间感到偏执，请直接调用QPF。

秒表基本上是本机QueryPerformanceCounter和QueryPerformanceFrequency方法的整洁包装。如果您不喜欢使用System.Diagnostic名称空间，则可以直接访问它们。

使用性能计数器非常普遍，这没有错。AFAIK，没有更高的计时器精度可用。请注意，QPF可能会导致多处理器计算机出现问题，但是之前链接的MSDN文章提供了有关此问题的其他信息。建议确保System.Diagnostics.Stopwatch在后台执行此SetThreadAffinity操作或手动调用-否则您的计时器可能会回到过去！

请注意，对于非常高精度的测量，需要考虑一些细微之处。如果您需要这么高的精度，这些可能会引起一些关注。

.NET基类库中有几种不同的计时器类-最能满足您需要的计时器类只能由您确定。

这是MSDN杂志上有关该主题的好文章（比较.NET Framework类库中的计时器类）。

根据您使用计时器的目的，您可能还需要考虑其他问题。Windows不提供执行时间的保证，因此您不应依赖它来进行任何实时处理（对于Windows，您可以获取提供实时实时扩展的实时扩展）。我还怀疑在捕获时间间隔之后以及在执行取决于其精度的操作之前，上下文切换可能会导致精度下降。原则上，这可能是任意长时间；实际上，它应该是毫秒级。这实际上取决于此时间的关键程度。