当进行基准测试时，什么原因导致CPU时间和“经过的实际时间”之间存在滞后？

Question

我正在使用内置的基准测试模块进行一些快速而粗略的测试。它给了我以下信息：

• CPU时间
• 系统CPU时间（实际上，我从我的代码中从来没有得到任何此项结果）
• 用户和系统CPU时间总和（在我的情况下始终与CPU时间相同）
• 经过的真实时间

我甚至不知道我需要所有这些信息。

我只想比较两段代码并查看哪一个需要更长的时间。我知道一段代码可能会执行更多的垃圾回收，但我不确定它会产生多大的影响。

有什么指标是我应该关注的吗？

最重要的是，有人能解释为什么“经过的真实时间”总是比CPU时间更长吗？是什么导致两者之间的滞后？

- Jeff

Answer 1

除了运行 Ruby 代码之外，系统中还有许多其他事情正在进行。流逝时间是总实际时间，不应该用于基准测试。你想要系统和用户 CPU 时间，因为这些是你的进程实际使用 CPU 的时间。

例如，如果你的进程：

• 使用 CPU 运行你的代码一秒钟；然后
• 使用 CPU 运行操作系统内核代码一秒钟；然后
• 被换出七秒钟，另一个进程运行；然后
• 再次使用 CPU 运行你的代码一秒钟，

你会看到：

• 十秒流逝时间，
• 两秒用户时间，
• 一秒系统时间，
• 三秒总 CPU 时间。

三秒是你需要关注的，因为十秒完全取决于进程调度的随机性。

- Pax

---

非常棒的解释。非常感谢。这真的为我解决了疑惑。 - Jeff

还有一个需要注意的效果：程序等待IO的时间不计入CPU时间。 - derobert

它不计入系统时间吗？ - Blaisorblade

有时候经过的时间会比CPU时间少。我猜测代码被分成不同的线程并在不同的CPU上运行，所以CPU时间超过了实际运行时间。（例如：当我在Incanter/Clojure基准测试[incanter-benchmark-master]（https://github.com/Quantisan/incanter-benchmark）上运行unix time时，我看到的运行时间略小于CPU时间。） - Mars

Answer 2

多任务操作系统，在等待I/O和其他时刻，你的代码不会主动运行。

- Chris Dolan

---

正确、简洁、不被琐碎的例子所淡化。我希望你的答案不会被低估。 - Devin Jeanpierre

嘿，@Devon，我不会把你的回答当作对我的个人攻击 :-) 如果示例可以增加理解，我更喜欢留下它们，无论它们有多琐碎。顺便说一句，你知道你的个人简介页面上写着你将在20010年参加实习吗？你认为你能活那么久吗？ - paxdiablo

欣赏在问题提问者的心中。我一点也不觉得被冒犯了。 :-) - Chris Dolan

Answer 3

您不应完全忽略挂钟时间。在没有其他线程准备好利用CPU周期的情况下等待的时间可能会使一段代码比另一段代码更不可取。一组代码可能需要更多的CPU时间，但是在现实世界中采用多线程来支配其他代码。这取决于要求和具体情况。我的观点是...利用所有可用的指标来做出决策。

此外，作为一个良好的实践，如果您想比较两个代码片段，应尽可能少地运行不必要的进程。

- jeffD

Answer 4

也有可能是在执行代码时，CPU时间没有被计算。

一个极端的例子是实时系统，定时器触发某些活动，这些活动总是比定时器滴答声短。这样，该活动的CPU时间可能永远不会被计算（取决于操作系统如何进行账务处理）。

- starblue