秒表基准testing是否可以接受？
有没有人使用秒表基准testing，或者应该总是使用性能工具？ 有什么好的免费工具可用于Java？ 你用什么工具？
为了澄清我的担忧，秒表基准testing由于操作系统调度而出现错误。 在您的程序运行时，操作系统可能会安排另一个进程（或多个进程）。 在Java中，如果您尝试使用线程化应用程序，那么情况会更糟，因为JVM调度程序甚至会将混乱中的一些随机性抛出。
基准testing时如何解决操作系统调度问题？
秒表基准testing是好的，只要你测量足够的迭代是有意义的。 通常情况下，我需要一定数量的单位数秒的总时间。 否则，您的结果很容易因计划安排和其他操作中断而显着偏离您的stream程。
为此，我使用了很久以前生成的一些静态方法，这些方法基于System.currentTimeMillis() 。
对于分析工作，我已经使用了jProfiler多年，并发现它非常好。 我最近浏览过YourKit ，这在网站上看起来很棒，但是我个人并没有使用它。
为了回答关于计划中断的问题，我发现重复运行直到实现一致性/观察在实践中消除了进程调度中的exception结果。 我也发现线程调度对5到30秒的运行没有实际的影响。 最后，按照我的经验，在通过几秒钟的门槛调度之后，对结果的影响可以忽略不计 – 我发现5秒的运行时间与迭代的5分钟运行时间保持一致。
您可能还需要考虑预先运行testing代码大约10,000次以“准备好”JIT，具体取决于您希望testing代码在现实生活中随时间stream逝的次数。
只要你测量足够的时间间隔，这是完全有效的。 我会执行你打算testing的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测量时间？
一个分析器给你更详细的信息，这可以帮助诊断和修复性能问题。
在实际测量方面，秒表时间是用户注意到的，所以如果你想validation事物是在可接受的范围内，秒表时间是好的。
但是，如果要真正解决问题，分析器可能会非常有用。
你需要testing一个实际的迭代次数，因为你会得到不同的答案，这取决于你如何testing时间。 如果您只执行一次操作，则可能会误导多次迭代的平均值。 如果你想知道JVM热身后所花费的时间，你可能会运行许多（例如10,000次）迭代，这些迭代不包括在时序中。
我也build议你使用System.nanoTime（）作为它更准确。 如果你的testing时间大概在10微秒或更less，你不想太频繁地调用它，或者它可以改变你的结果。 （例如，如果我正在testing5秒钟，并且想知道什么时候结束，那么每1000次迭代只能得到一次nanoTime，如果我知道迭代非常快的话）
秒表实际上是最好的基准！
真正的端到端用户响应时间是真正重要的时间。
使用可用的工具获得这个时间并不总是可能的，例如大多数testing工具不包括浏览器渲染页面所需的时间，所以一个写得不好的过度复杂的页面会显示次要的testing响应时间工具，但是，5秒加上对用户的响应时间。
这些工具非常适合自动化testing，并且可以帮助您确定问题，但不要忽视您真正想要测量的内容。
Profiler可能会影响计时，所以我会结合使用秒表计时来识别整体性能问题，然后使用分析器计算出花费的时间。 根据需要重复。
我今天运行了一个程序，search并收集了一系列dBase文件的信息，运行了一个多小时。 我看了一下代码，猜测瓶颈是什么，对algorithm做了小小的改进，重新执行了程序，这次在2.5分钟内完成。 我不需要任何奇特的分析工具或基准套件来告诉我新版本是一个重大的改进。 如果我需要进一步优化运行时间，我可能会做一些更复杂的分析，但这不是必要的。 我发现这种“秒表基准testing”在许多情况下是可接受的解决scheme，在这些情况下采用更先进的工具实际上会更费时间。
毕竟，这可能是第二个最受欢迎的基准testingforms，就是在“无基准testing”之后 – 我们说“这个活动看起来很慢，似乎很快”。
通常，优化最重要的是什么干扰用户体验 – 这通常是您执行操作的频率以及同时进行的其他操作的function。 其他forms的基准往往只是帮助零这些。
我认为一个关键的问题是操作的复杂性和时间长度。
我有时甚至使用物理秒表测量，看看是否需要几分钟，几小时，几天，甚至几周来计算（我正在与一个应用程序的几天的订单运行时间是不是闻所未闻的，即使秒和分钟是最常见的时间跨度）。
然而，通过调用计算机上的任何一种时钟系统所提供的自动化，如链接文章中提到的java millis调用，明显优于手动查看运行多长时间。
Profiler在工作的时候是很好的，但是我在将它们应用到我们的应用程序时遇到了问题，这些应用程序通常涉及到dynamic代码生成，DLL的dynamic加载，以及两种内置的即时编译脚本语言我的应用程序。 他们往往仅限于采用单一的源语言和对复杂软件的其他不切实际的期望。
基准testing时，如何解决操作系统调度问题？
基准testing的时间足够长，代表你将要使用的机器。 如果你的操作系统减慢你的应用程序，那么这应该是结果的一部分。
没有必要说，如果我没有一个操作系统，我的程序会更快。
如果您正在使用Linux ，则可以使用numactl ， taskset和taskset等工具来控制如何使用CPU以及调度。
我不认为秒表基准testing是太可怕了，但是如果你能进入Solaris或OS X机器，你应该检查出DTrace。 我用它来获取关于我的应用程序的时间的一些很好的信息。
我总是使用秒表基准testing，因为它更容易。 虽然结果不需要非常准确。 如果你需要准确的结果，那么你不应该使用秒表基准。
我一直这样做。 我宁愿使用分析器，但我正在使用的特定于域的语言的供应商不提供。
