我正在 Intel Core-2Duo 平台上对 Microsoft VS 2005 中的 C 代码进行分析。我测量了我的函数所消耗的时间（秒：毫秒）。但我对这种测量的准确性有些怀疑，因为操作系统不会连续运行我的应用程序，而是在我的代码执行之间安排其他应用程序/服务。（虽然我在执行配置文件时没有运行主要应用程序运行，Windows 仍然会有很多自己的代码，它将通过抢占我的应用程序来运行。）。由于这一切，我认为分析编号（我的应用程序运行所花费的时间）不准确。
所以我的问题是有什么方法可以找出操作系统开销，在典型的 Windows 系统（我运行 Windows XP）上调度开销，例如，如果我的应用程序说它运行了 60 毫秒，那么在 60 毫秒中，真正的时间是多少？我的应用程序使用。由于被操作系统安排的其他任务抢占了，它闲置了多少时间？
或者
根据您在做类似事情时遇到的经验，至少有没有任何可能的数字来获得这样的操作系统开销？
@Kogus：即使我在调试器之外运行（独立应用程序。从命令提示符）它仍然可能被操作系统抢占并导致我的应用程序消耗的时间测量不正确。
不是吗？
-广告
我认为您将在粒度方面遇到一些问题。查看类似的问题GetLocalTime() API 时间分辨率和是否保证 gettimeofday() 具有微秒分辨率？
此外，您可能想查看包含 timeit.exe（类似于unix/linux 上的）的Windows 资源工具包工具，以提供经过时间和处理时间。time
建议
尝试在多 CPU 系统上运行。
1 - 在您的代码中添加一些调试日志（当然包括时间戳），并在调试器之外运行它
2 -在调试器中再次运行
3 - 重复多次，以获得统计上有效的数据。
4 - 比较。
如果独立与调试器的平均执行时间存在显着差异，那么您应该怀疑操作系统（或调试器挂钩本身的开销......）。如果没有区别，那就不要出汗。
Edit0：显然调试消息有自己的一些开销。即使从调试器运行，您也可能希望将这些保留在代码中。这样，独立和调试器都运行相同的代码。
Edit1：我误解了这个问题。我认为您担心的是——在调试时——操作系统可能会比正常执行模式更频繁地中断您的应用程序。如果您想知道您的应用实际花费了多少时间，只需将花费的时间与任务管理器中的“CPU 时间”进行比较即可。
Edit2：将GetProcessTimes为您的进程返回的时间与实际执行时间进行比较。区别在于 CPU 花费在其他人身上的时间。
最好的方法是使用专用的分析工具。那里有很多。我已经有几年没有使用过 C 语言了，希望其他人能够提供更好的建议。当您使用 Visual Studio 2005 时，这可能是一个不错的起点： AQ，但我从未使用过它。