在我们的项目中，我们会尝试自动监控测试运行的性能，以确保我们不会对程序的性能产生任何重大变化。
问题是我们得到的措施似乎有一致的5％可变性。也就是说，在运行相同测试的相同程序（无重新编译）的同一台机器上，我们得到的值在运行之间相差约5％。这对我们想要使用数字的方式来说太过分了。
我们已经从时间考虑因素中排除了设置成本 - 也就是说，从C ++代码本身开始，我们会在运行时间关键部分之前和之后抓住时间，而不是在操作系统级别的整个程序。我们也在进行平均和异常值排除。问题在于变异性看起来也具有长期趋势，因此我们会在重复之后紧密聚集时间，但是一两个小时之后的时间会大不相同。 （不幸的是，将测试分散几个小时是不可行的。）测试也在专用机器上进行，而没有别的＆＃34;正在运行它。
我们不太确定时序变化的来源，但它可能与处理器和系统有关 - 有迹象表明可变性的大小取决于程序的机器正在运行。
有没有人知道这种变化可能来自哪里，以及如何删除它？测试在专用机器上运行，因此可以更改操作系统设置。
（如标签所示，这是在x86 Linux系统上运行的C ++程序，如果这有助于澄清事情。）
编辑：对评论的回应
我们当前的时序方案是使用C标准库中的clock（）函数，查看我们想要测试的函数之前/之后的返回值的差异。
我们正在测试的代码应该是确定性的，不应该涉及大量IO。
我意识到这种情况对于一颗银弹来说有点朦胧＆＃34;回答。我想我更多地寻找一个＆＃34;这些是重要的考虑因素，这是你应该检查它们的顺序，这里是你如何检查它们和＆＃34; ＃34;输入答案。
答案 0 :(得分：2)
我很惊讶你的变化达到了5％。
除非您能够摆脱系统上运行的所有不必要的事情，否则您将获得高度变化。这是最高级别的。
您的操作系统需要具有确定性。您需要知道正在运行的其他任务和线程及其持续时间。例如，有时钟中断。现在，有多少其他函数被链接到这个中断？这些其他功能有所不同吗？
你的系统是否被隔离？例如，如果系统连接到网络，您的测量结果可能会有所不同。
您的程序是否使用外部资源？例如硬盘。如果程序写入硬盘驱动器，则驱动器将不具有确定性。文件和文件的一部分可能会在驱动器上移动。驱动器可能会碎片化。这种碎片可能会导致测量结果出现差异。
操作系统内存可能会碎片化。此外，可执行文件的内存可能会碎片化。碎片可能会增加差异。