3

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

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

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

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

我应该查看哪个指标的任何想法？

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

4

4 回答 4

9

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

例如，如果您的流程：

  • 使用 CPU 运行代码一秒钟；然后
  • 使用 CPU 运行 OS 内核代码一秒钟；然后
  • 在另一个进程运行时被换出七秒钟；然后
  • 使用 CPU 多一秒钟来运行你的代码，

你会看到：

  • 十秒过去的时间，
  • 两秒的用户时间，
  • 一秒系统时间，
  • 三秒的总 CPU 时间。

三秒是您需要担心的，因为这十秒完全取决于进程调度的变幻莫测。

于 2009-03-21T03:38:03.673 回答
5

多任务操作系统，等待 I/O 时的停顿，以及其他代码不活跃的时刻。

于 2009-03-21T03:33:33.793 回答
3

You don't want to totally discount clock-on-the-wall time. Time used to wait w/o another thread ready to utilize CPU cycles may make one piece of code less desirable than another. One set of code may take some more CPU time, but, employ multi-threading to dominate over the other code in the real world. Depends on requirements and specifics. My point is ... use all metrics available to you to make your decision.

Also, as a good practice, if you want to compare two pieces of code you should be running as few extraneous processes as possible.

于 2009-03-21T07:42:42.103 回答
2

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

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

于 2009-03-21T07:42:34.100 回答