标杆经验教训:"难"的办法
据悉基准的经验教训
最近花太多时间基准不同的代码，这里有一些教训教训！在没有特定的顺序:确保您机器上所有节电系统关闭:该图显示在一个进程中运行的基准。进程正在运行的JVM的COBOL相同的计算，一遍又一遍。虽然这个过程是接近100％占用一个单核的机器，这只占50％作为一个整体的CPU负载。操作系统没有足够聪明，算出这个，所以CPU的时钟速度不断缩减。当一些虚假的IO操作或其他活动所造成的CPU使用率进一步下降，缩放更切。这trashes的基准测试结果，尤其是当比较不同的CPU负载特性不同的软件技术。确保没有其他计算机上运行:"确定"，这是非常一个现代化的机器上是不可能的。不过，我不敢想多少次了一个基准可怕的，我错了，因为Outlook选择"那一刻"，以更新其所有的文件夹。一个讨厌的一个检查您的网络浏览器。 Flash动画和AJAX页面可以随意消耗大量的CPU或磁盘，你永远不知道它。检查是否使用了"顶"或Process Explorer（* NIX或Windows）。测试真实的情景:假设一个简单的循环，将不足以衡量一个语言或技术的性能，这是很容易。它不是！大多数现代编译器有哪些具体的目标循环的优化。简单循环得到优化大规模或完全优化掉。然而，在现实生活中发生的更复杂的循环，并没有得到优化。所以，一个简单的循环，可以产生的结果没有类似现实世界中的性能的方式。
下面是一个简单的循环的COBOL程序:
我们可以看到，A和B是不变的，R是循环常数（1或1000次迭代后，它是相同的的）。此外，计数器都有一个固定的值在编译时，可以推导出循环结束。在我在后，我展示了一个使用JavaScript的基准技术。下面是64位Windows 64位COBOL（opt选项）和64位的Sun / Oracle的JVM的结果:{C}
启动开销的COBOL并没有在所有（计划说:"GoBack的。"）时的性能。它是从明确的结果为母语的微聚焦，做什么都没有执行循环之间的区别是小于基准技术错误。可能是由于其他进程使用的CPU和内存的机器上的变化。这是一个令人印象深刻的位从微聚焦本地代码生成器的优化。
JVM中的COBOL以及不执行。它的推出琐碎的开销，所以在这个测试中，它是数万，如果不是比原生的COBOL慢数百倍。这是现实世界的现实的结果呢？我们可以证明，它不是，因为常量的值循环不发生在生产代码非常（为什么有一个循环，它什么也不做呢？）。 JVM的COBOL不优化掉这个循环。
会发生什么情况如果循环是较难预测的呢？ therelative JVM的性能和原生变化的差异吗？
现在，我们可以看一个稍微复杂的程序:123456$set sourceformat(variable)
01 my-group.
03 counter pic s9(9) comp-5.
03 a pic s9(9) comp-5.
03 b pic s9(9) comp-5.
03 r pic s9(9) comp-5.
01 resuts.
03 rr pic x(40).
03 rc pic x(40).
move 123456788 to b
move 100 to r
perform varying counter from 1 by 1
until counter = 1000000
move 123456789 to a
compute r = counter / 100
compute r = counter - r * 100
compute a = a + r
compute r = (a + b) / (a - b)
compute r = (r + b) / (a - b)
compute r = (r + b) / (a - b)
compute r = (r + b) / (a - b)
compute r = (r + b) / (a - b)
if r = 0
exit perform
end-if
end-perform
move r to rr
move counter to rc
.
在这个程序中，A和R不再循环常数。此外，循环计数器= 1000000之前退出。这意味着，优化器可以不再优化循环。这种复杂的分支逻辑，业务逻辑在实际程序运行的方式，更典型。
下面是结果:Results:
=========
JVM
Maximum Time: 449
Minimum Time: 189
Mean Time: 202.9375
Total Time: 6494
Native
Maximum Time: 167
Minimum Time: 145
Mean Time: 148.8125
Total Time: 4762
会计一个1.7秒的启动开销，这个基准测试显示本机的COBOL运行速度比JVM中的COBOL只有约2.0倍。
由此看来，这是非常清楚，简单的循环，在没有为基准的方式！选择有代表性的硬件:不要基准，一个SATA驱动器的机器上的数据库应用程序和期望，像一台机器上运行一个串行SCSI RAID！即使使用同一台机器上设置的x86和x64_86指令的性能可以完全不同。
下面是我上面所讨论的为基准的结果，但这次使用的是64位的机器上的32位x86代码:
这一次推出的开销较低，以及为母语（1.4秒和0.2秒的JVM）。因此，我们必须为母语的5.7秒和6.8 JVM中的COBOL，这意味着在32位本机运行的COBOL是只有1.2倍，比JVM，这实质上完全相同机上的64位结果的不同更快。知道你的敌人，它花费的时间。
{A2}