在准确地确定algorithm在我的程序中运行的速度时，我一直使用QueryPerformanceCounter（）和QueryPerformanceFrequency（），但是当我使用核心i5 / 7架构时会发生什么？
是否有可能涡轮增压会突然踢我的algorithm的一半，突然我的表演计时器不再准确，因为我的时钟频率不再是一个常数，或者这真的不是一个问题？ 如果这是一个问题，那么准确计算algorithm的更好方法是什么？
简而言之，是的，任何事情都可能发生。 现代CPU只是简单地估计真实世界的表现，该死的难以做到。 这并不仅限于最新的Intel x86-64 cpus，它同样适用于8位PIC微控制器，以及其他所有内容。
要做的唯一合理的事情就是测试更多。 您将需要执行许多重复测试，才能获得关于实际工作负载的实际硬件上实际运行时性能的准确概念。
另一方面，如果一个算法在同一个硬件（“在我的机器上”）上优于另一个算法，那么它通常会在其他设置上给出类似的比较结果，尽管它可能会以一个常数因子变化。
以下是关于QueryPerformanceCounter主题的一篇有趣的文章：
http://www.virtualdub.org/blog/pivot/entry.php?id=106
显然，VirtualDub的哥们停止使用它，现在有利于timeGetTime 。 一个很好的阅读。
我建议使用Boost.Date_Time ，特别是boost :: posix_time的东西。
实际上有两个单独的问题在这里：
当CPU时钟频率改变（或者通过例如Turbo Boost增加或者由于例如省电或者热管理踢入而降低）时，任何给定定时方法的可靠性 – 这在一些其他答案
基准测量的可靠性（给定可靠的时钟） – 这是更有问题的 – 如果您正在进行优化并寻找小的改进，例如10％左右，那么很容易被来自Turbo Boost的时钟变化的影响误导在等。 可能的解决方案是
2.1。 禁用Turbo Boost和其他时钟频率缩放
2.2。 运行基准足够长的时间来平均时钟速度的变化
QPC的时钟源传统上从来没有从时钟频率中获得。 主板厂商一直在偷工减料，试图削减一两分钱。 他们通常从某个芯片组中挑选一个频率。 我听说有人的AMD机器的QPF值为2GHz，这个危险性接近于CPU时钟倍增后的值。 如果你得到这样一个大的价值，只有紧张。
QPC的绝对价值永远不应该成为您的担忧。 这将主要取决于核心的质量。 只有使用QPC测量才能查看代码的渐进式改进。