秒表基准测试可以接受吗？

是否有人曾经使用秒表基准测试，还是应该一直使用性能工具？是否有适用于Java的良好免费工具？您使用什么工具？

为了澄清我的担忧，秒表基准测试会因操作系统调度而出错。在给定的程序运行中，操作系统可能会在您要计时的功能中间安排另一个（或几个）进程。在Java中，如果您想定时一个线程化的应用程序，情况会变得更糟，因为JVM调度程序将更多的随机性引入了混合中。

基准测试时如何处理操作系统调度？

只要您测量足够有意义的迭代，秒表基准测试就可以了。通常，我需要的总经过时间为几位数的秒数。否则，您的结果很容易因计划安排和流程的其他O / S中断而明显偏斜。

为此，我使用了很久以前基于的一些静态方法System.currentTimeMillis()。

对于分析工作，我使用jProfiler已经很多年了，并且发现它非常好。最近，我查看了YourKit，它在WebSite上看起来不错，但是我个人还没有使用过它。

为了回答有关计划中断的问题，我发现重复执行直到达到一致性/在实践中观察到的工作才能清除流程计划中的异常结果。我还发现线程调度对于5到30秒的运行没有实际影响。最后，根据我的经验，经过几秒钟后，阈值计划对结果的影响可以忽略不计-我发现5秒钟的运行时间和迭代5分钟的运行时间平均相同。

您可能还需要考虑将测试的代码预运行约10,000次以“热身” JIT，具体取决于您希望测试的代码在现实生活中随着时间的推移而运行的次数。

只要您测量足够大的时间间隔，它就完全有效。我将执行20-30次您打算测试的运行，以使总经过时间超过1秒。我注意到基于System.currentTimeMillis（）的时间计算通常为0ms或〜30ms；我认为您没有比这更精确的方法了。如果您确实需要测量一个小的时间间隔，则可能需要尝试System.nanoTime（）：

• 文档：http : //java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime（）
• 由于System.nanoTime（）也存在一些问题，因此也存在有关测量小时间跨度的问题：如何在Java中以微秒精度测量时间？

秒表实际上是最好的基准！

真正的端到端用户响应时间是真正重要的时间。

并非总是可以使用可用的工具获得该时间，例如，大多数测试工具并未包括浏览器呈现页面所花费的时间，因此，css编写错误的过于复杂的页面将显示对测试的响应时间。工具，但需要5秒钟，再加上对用户的响应时间。

这些工具非常适合用于自动化测试和问题确定，但不会遗漏您真正想要衡量的内容。

探查器为您提供了更详细的信息，可以帮助诊断和修复性能问题。

就实际测量而言，秒表时间是用户注意到的，因此，如果您要验证事情是否在可接受的范围内，秒表时间就可以了。

但是，当您要实际解决问题时，探查器可能会非常有用。

您需要测试实际的迭代次数，因为您将根据测试时序的方式获得不同的答案。如果只执行一次操作，则取多次迭代的平均值可能会产生误导。如果您想知道JVM预热之后所花费的时间，则可以运行许多（例如10,000）迭代，这些迭代未包括在计时中。

我也建议您使用，System.nanoTime()因为它更准确。如果您的测试时间在10微秒或更短的时间内，则您不想经常调用它，否则它会改变您的结果。（例如，如果我要测试5秒钟，并且我想知道何时启动，则每隔1000次迭代我只会获得nanoTime，如果我知道迭代非常快）

基准测试时如何处理操作系统调度？

在代表您将要使用的计算机的系统上进行足够长的基准测试。如果您的操作系统降低了应用程序的速度，那么这应该是结果的一部分。

没什么可说的，如果我没有操作系统，我的程序就会更快。

如果使用Linux，则可以使用诸如和的工具numactl，以控制CPU的使用方式和计划。chrttaskset

探查器可能会妨碍计时，因此我将结合使用秒表计时来确定总体性能问题，然后使用探查器来确定花费的时间。根据需要重复该过程。

毕竟，它可能是第二种最流行的基准测试形式，仅次于“无监视基准测试”。在这种情况下，我们说“此活动似乎很慢，但似乎很快。”

通常，最重要的优化因素是影响用户体验的因素-这通常取决于您执行操作的频率以及同时发生的其他事情。其他形式的基准测试通常只能帮助实现这些目标。

我认为关键问题是手术的复杂性和时间长度。

有时，我什至使用物理秒表测量来查看是否需要花费几分钟，几小时，几天甚至几周的时间来计算（我正在使用的应用程序即使在数秒和数分钟的时间里也不会闻闻几天的运行时间最常见的时间跨度）。

但是，通过调用计算机上任何类型的时钟系统（如链接的文章中提到的java millis调用）所提供的自动化明显优于手动查看某项运行了多长时间。

探查器在工作时很好用，但是我在将它们应用到我们的应用程序时遇到了问题，通常涉及动态代码生成，DLL的动态加载以及使用两种内置的即时编译脚本语言进行的工作。我的应用程序。它们通常仅限于假设单一的源语言以及对复杂软件的其他不切实际的期望。

今天，我运行了一个程序，该程序从一堆dBase文件中搜索并收集了信息，运行只花了一个多小时。我看了一下代码，对瓶颈问题进行了有根据的猜测，对算法进行了小幅改进，然后重新运行了程序，这次它在2.5分钟内完成了。

我不需要任何精美的性能分析工具或基准套件就可以告诉我新版本是一项重大改进。如果需要进一步优化运行时间，我可能会做一些更复杂的分析，但这不是必需的。我发现在许多情况下，这种“秒表基准测试”是可以接受的解决方案，在这些情况下，诉诸更高级的工具实际上会更加耗时。

我认为秒表基准测试并不是太可怕了，但是如果您可以使用Solaris或OS X计算机，则应该查看DTrace。我用它来获取有关我的应用程序中计时的重要信息。

我总是使用秒表基准测试，因为它非常容易。结果对我来说并不需要非常准确。如果您需要准确的结果，则不应使用秒表基准测试。

我一直都在做。我宁愿使用探查器，但是与我合作的特定领域语言的供应商却没有提供探查器。