基准测试时，是什么导致CPU时间和“实时流逝”之间的延迟？

Question

我正在使用内置的基准测试模块进行一些快速而肮脏的测试。它给了我：

• CPU时间
• 系统CPU时间（实际上我从来没有得到任何结果，我正在运行的代码）
• 用户和系统CPU时间的总和（总是与我的情况下的CPU时间相同）
• 已用实时

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

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

我应该关注哪些指标？

而且，最重要的是，有人可以解释为什么“经过实时”总是比CPU时间长 - 导致两者之间滞后的原因是什么？

Answer 1

除了运行Ruby代码之外，系统中还有很多事情要发生。经过的时间是实际采用的总时间，不应用于基准测试。您需要系统和用户CPU时间，因为这些是您的进程实际拥有CPU的时间。

一个例子，如果你的过程：

• 使用CPU运行代码一秒钟;然后
• 使用CPU运行一秒钟的OS内核代码;然后
另一个进程运行时，
• 换掉了七秒钟;然后
• 使用CPU再运行一下代码，

你会看到：

• 经过十秒钟，
• 两秒钟的用户时间，
• 一秒系统时间，
• 总CPU时间为3秒。

三秒钟是您需要担心的，因为十分完全取决于流程安排的变幻莫测。

Answer 2

多任务操作系统，在等待I / O时停止，以及代码处于不活动状态的其他时刻。

Answer 3

你不想完全打折时间。用于等待另一个准备好利用CPU周期的线程的时间可能使得一个代码比另一个更不可取。一组代码可能需要更多的CPU时间，但是，使用多线程来支配现实世界中的其他代码。取决于要求和细节。我的观点是......使用所有可用的指标来做出决定。

另外，作为一种好的做法，如果你想比较两段代码，你应该运行尽可能少的无关过程。

Answer 4

也可能是代码执行时的CPU时间不计算在内。

极端的例子是一个实时系统，其中计时器触发一些总是比计时器滴答短的活动。然后，可能永远不会计算该活动的CPU时间（取决于操作系统如何进行记帐）。