运行"milli"-benchmarks是个好主意吗？

Question

我刚刚看到了卡利珀项目，它看上去很不错。阅读微基准简介，人们会感觉到，如果基准测试花费的时间超过一秒左右，开发人员就不会建议使用该框架。我看了代码，如果一个场景执行时间超过10s，它看起来就像抛出了一个RuntimeOutOfRangeException。

你能向我解释一下运行更大的基准有什么问题吗？

我使用卡利珀的动机是比较两种连接算法实现。这些操作肯定会运行相当长的时间，并且会执行一些磁盘IO操作，但是运行整个数据库将很难进行比较，因为算法的配置和结果的可视化将是一件痛苦的事。

Answer 1

使用卡尺而不是天真地编写自己的基准代码的原因之一是，卡尺可以很大程度上避免编写微基准测试的一些缺陷。例如，一个好的基准测试应该首先在预热阶段运行代码，以确保所有相关代码都获得JITed。它还应该确保执行两倍多的迭代需要两倍的时间；如果不是，它意味着JVM正在优化工作。

所有这一切都意味着，要正确地对代码进行基准测试，卡尺需要运行大量的迭代。对于一个以微秒为单位的任务来说，这是合理的。但是，如果一次迭代需要超过10秒，这意味着卡尺运行需要很长的时间。我的假设是，卡里珀团队认为，由于这个原因，运行时间超过10秒的任务更有可能是程序员错误的结果，而不是刻意选择编写一个需要数小时运行的基准。通过提前退出，它可以帮助程序员迅速意识到他们需要修复一个bug，而不是让他们的机器运转数小时。

Answer 2

许多代码减速发生在小的、紧的循环中。如果您知道这是您花费时间的地方，那么一个微基准可以帮助您优化这一小部分代码。

单元测试需要在合理的时间内完成。对于我来说，编写一个需要超过一秒或两秒钟时间执行的单元测试是非常罕见的，因为我在测试程序集中可能有两三百个这样的测试，或者更多。

Answer 3

测试驱动设计的一个想法是在构建项目时运行所有的单元测试，这允许您在提交导致它们的更改之前快速捕获功能回归。但是，要使这一工作奏效，所有的测试都需要快速完成。

如果您的基准测试都运行得很快，那么它们可以包含在您的测试框架中(我不知道这是否是杯杯的目的，但是Google非常关注TDD.)。在任何情况下，向测试驱动的基础结构添加基准都是为了快速捕获主要的性能回归--因此，对于这种用法，您可能希望将错误标记得太长。