是否有人使用过秒表基准测试，或者是否应该始终使用性能工具？是否有任何可用于 Java 的好的免费工具？你用什么工具？
为了澄清我的担忧，秒表基准测试可能会因操作系统调度而出错。在程序的给定运行中，操作系统可能会在您正在计时的功能中间安排另一个（或多个）进程。在 Java 中，如果您尝试为线程应用程序计时，情况会更糟，因为 JVM 调度程序会在其中加入更多随机性。
基准测试时如何解决操作系统调度问题？
【问题讨论】：
标签： java benchmarking
我总是使用秒表基准测试，因为它更容易。结果对我来说不需要非常准确。如果您需要准确的结果，则不应使用秒表基准测试。
【讨论】：
我不认为秒表基准测试太可怕了，但是如果您可以使用 Solaris 或 OS X 机器，您应该查看 DTrace。我已经使用它来获取有关我的应用程序中计时的一些重要信息。
【讨论】：
秒表基准测试很好，只要您测量足够次迭代是有意义的。通常，我需要一些个位数秒的总经过时间。否则，您的结果很容易因调度和流程的其他 O/S 中断而严重偏离。
为此，我使用了一些我很久以前构建的静态方法，它们基于System.currentTimeMillis()。
对于分析工作，我使用jProfiler 多年，发现它非常好。我最近查看了YourKit，从网站上看起来很棒，但我个人根本没有使用过。
为了回答有关调度中断的问题，我发现重复运行直到达到/观察到一致性在实践中可以清除进程调度的异常结果。我还发现线程调度对于 5 到 30 秒之间的运行没有实际影响。最后，根据我的经验，在您通过几秒阈值之后，调度对结果的影响可以忽略不计 - 我发现 5 秒的运行始终与 5 分钟的时间/迭代运行相同。
您可能还需要考虑预先运行大约 10,000 次测试代码以“预热” JIT，具体取决于您期望测试代码在现实生活中随着时间的推移运行的次数。
【讨论】：
分析器为您提供更详细的信息，有助于诊断和修复性能问题。
就实际测量而言，秒表时间是用户注意到的，所以如果您想验证事情是否在可接受的范围内，秒表时间就可以了。
但是，当您想真正解决问题时，分析器会非常有用。
【讨论】：
我今天运行了一个程序，它从一堆 dBase 文件中搜索并收集信息，运行它只花了 一个多小时。我查看了代码，对瓶颈进行了有根据的猜测，对算法进行了小幅改进，然后重新运行了程序，这次它在 2.5 分钟内完成。
我不需要任何花哨的分析工具或基准套件来告诉我新版本是一项重大改进。如果我需要进一步优化运行时间，我可能会做一些更复杂的分析，但这不是必需的。我发现这种“秒表基准测试”在很多情况下都是可以接受的解决方案，而在这些情况下使用更高级的工具实际上会更耗时。
【讨论】：
我一直这样做。我更愿意使用分析器，但我正在使用的特定领域语言的供应商没有提供。
【讨论】：
只要您测量足够大的时间间隔，它就完全有效。我会执行 20-30 次您打算测试的运行，以便总经过时间超过 1 秒。我注意到基于 System.currentTimeMillis() 的时间计算往往是 0ms 或 ~30ms；我不认为你能得到比这更精确的东西。如果你真的需要测量一个小的时间间隔，你可能想试试 System.nanoTime()：
【讨论】：
毕竟，它可能是第二种最流行的基准测试形式，仅次于“不观看基准测试”——我们说“这个活动看起来很慢，那个看起来很快。”
通常最重要的优化是干扰用户体验的内容 - 这通常取决于您执行操作的频率以及同时发生的其他任何事情。其他形式的基准测试通常只是帮助在这些方面归零。
【讨论】：
分析器可能会妨碍计时，因此我会结合使用秒表计时来识别整体性能问题，然后使用分析器来确定时间花在哪里。根据需要重复该过程。
【讨论】：
我认为一个关键问题是操作的复杂性和时间长度。
我有时甚至使用物理秒表测量来查看计算是否需要几分钟、几小时、几天甚至几周的时间（我正在使用一个应用程序，即使几秒钟的运行时间也不是闻所未闻的几天和分钟是最常见的时间跨度）。
但是，调用计算机上任何类型的时钟系统（如链接文章中提到的 java millis 调用）所提供的自动化显然优于手动查看某项运行的时间。
分析器在工作时很好用，但我在将它们应用到我们的应用程序时遇到了问题，这通常涉及动态代码生成、动态加载 DLL 以及在两个内置的即时编译中执行的工作我的应用程序的脚本语言。它们通常仅限于假设单一源语言和对复杂软件的其他不切实际的期望。
【讨论】：
秒表实际上是最好的基准！
真正的端到端用户响应时间是真正重要的时间。
使用可用的工具并不总是可以获得这个时间，例如大多数测试工具不包括浏览器呈现页面所花费的时间，因此一个具有糟糕 css 编写的过于复杂的页面将显示亚秒级响应时间到测试工具，但是，5 秒加上对用户的响应时间。
这些工具非常适合自动化测试和问题确定，但不要忽视您真正想要测量的内容。
【讨论】：
您需要测试实际数量的迭代，因为根据您测试时间的方式，您会得到不同的答案。如果您只执行一次操作，那么取多次迭代的平均值可能会产生误导。如果您想知道 JVM 预热后所需的时间，您可能会运行许多（例如 10,000 次）迭代，这些迭代不包括在计时中。
我还建议您使用System.nanoTime()，因为它更准确。如果您的测试时间大约为 10 微秒或更短，您不想太频繁地调用它，否则它会改变您的结果。 （例如，如果我正在测试 5 秒并且我想知道它什么时候结束，如果我知道迭代非常快，我只会每 1000 次迭代获得一次 nanoTime）
【讨论】：
基准测试时如何解决操作系统调度问题？
在代表您将使用的机器的系统上进行足够长的基准测试。如果您的操作系统降低了您的应用程序的速度，那么这应该是结果的一部分。
不用说，如果我没有操作系统，我的程序会更快。
如果您使用Linux，则可以使用numactl、chrt 和taskset 等工具来控制CPU 的使用方式和调度。
【讨论】：