1

我目前正在维护一种算法，该算法使用挂钟时间来做出各种决定（例如，哪些解决方案可以快速计算，哪些解决方案需要很长时间并且需要废弃）。

在尝试测试算法时，由于机器负载、操作系统调度、IO 等任意数量的变量，每次结果都可能略有不同。

测试这样一个系统的标准方法是什么？执行 CPU 指令之类的东西是我的一个想法，但是我不确定这在现代多核 x86 处理器上有多实用。

后备计划是向内部计数器添加增量并更改算法的限制以尝试匹配现有挂钟版本的性能。然而，这将涉及大量的试验和错误，所以我想知道在我开始走这条路之前是否有更简单的方法。

4

2 回答 2

2

简单但粗略的选择是“抽象掉”墙上时间检索逻辑。

比如说，使用WallTime带有GetTime方法的类并在整个应用程序中使用它。

这个类可以使用两个时间“提供者”。一是系统中的RT时钟。

另一个只是从预先记录的列表中返回值。

您记录第一次通过算法并存储返回的值GetTime。这些值将形成第二个“时间提供者”的“预先记录”值列表。

假设第二次运行将以GetTime完全相同的顺序调用，您可以简单地返回与第一次运行相同的时间值:)

如果您想调整一些时间，您也可以编辑列表。您还可以有多个存储列表，以模拟不同的硬件。

例子：

假设算法是这样工作的：

  1. GetTime-> 从时钟返回 T1
  2. 调用函数 X
  3. GetTime-> 从时钟返回 T2
  4. Y根据 (T2 - T1)决定接下来要调用的函数（例如）
  5. GetTime-> 从时钟返回 T3
  6. 调用函数Y
  7. GetTime-> 从时钟返回 T4 ...

将 T1、T2、T3 和 T4 保存在列表中后，您可以准确地重播上述运行（关于返回的值GetTime）。

如果在第 6 步执行的函数（这是您的算法根据性能选择的函数）在第二次运行中不同，即使 (T2 - T1) 时间差相同，则此解决方案将失败，即取决于在一个可变的、非时间相关的参数上。

于 2013-04-20T09:32:44.353 回答
0

我喜欢@Andrei 的解决方案，但根据您的描述，您的算法似乎并不总是以相同的顺序进行计时调用。在这种情况下，我可能会创建一个简单的WallClockTimer类，它可以按名称/枚举记录各种持续时间（使用 和 之类的方法startTimerFor(SOME_KEY)）getElapsedTimeFor(SOME_KEY)。您的算法将与此计时器协作以做出其运行时决策。要测试这些决定，您可以MockWallClockTimer为给定的键返回预先指定的持续时间。

于 2013-04-20T15:20:57.657 回答