有何不同？Opera 9.5新版性能测试

　　近日，Opera公司发布了其浏览器新版本（9.5x系列，开发代号为Kestrel），其中一个重要想法就是为了全面地提高其性能表现。与之前的版本相比（9.x，开发代号为Merlin），这个版本拥有一个新的ECMAScript引擎，并且对页面渲染做了比较重大的修改。通过一些科学的测试方法，我们可以量化Opera性能到底发生了哪些改变。

　　首先，我们要了解一下组成浏览器的各个子系统，每一个部分都会对整体表现产生影响。因为一个浏览器除了能够快速滚动及显示中心透明的PNG图片外，它也刚好可以用来浏览你最喜欢的网站！尽管不可能完全覆盖所有的各方面的性能测试，但我们可以通过一个跨样本的渲染子系统来测试其处理速度。我已经选择把重点放在ECMAScript和DOM操作上，因为现在很多网站开发的页面里，这两个已经逐渐成为重要的应用。当然，我还会使用三个真实的页面来进行测试，下面看看测试结果吧。

　　测试环境

　　以下所有的测试都是在一台主频2G HZ、内存2GB的Macbook苹果笔记本电脑上进行的，XP SP2操作系统，已经打上了所有的补丁，系统干净无其他程序。OS X版本是10.4.10，也已全面更新。

　　真的有什么不同吗？

　　有一件让我感到困惑的事，就是我看到在网上公布的标准大部分都是给出完全缺少错误的信息。如果我测试某个对象A，五次测试我可能得到：1.8, 6.5, 3.4, 11.5, 6.1五个数据,它们的平均值是5.84。但是实际的值却不一定是5.84。所以如果我测试了某个对象B而得到6.48，虽然这是比对象A的平均数值高。但是这种不稳定的测试意味着我并不能说这是真的“不同”。就凭我们在这里看到的一些情况，我已经考虑了99.9％的有重大影响的限制，所以关于这些不稳定性的数值的获取，我可以给你更好的建议。这里有一个例子，记得这个褐色矩形的底部是正的可信区间，负区间是在主栏的后面。存在的区间表示，经过反复的测试，有99.9%的值预计是属于在盒子中类似地使用。有些人声称对象A在5.4时比对象B在6.1时更小，但看可信区间，它更难与某些作用相同。

　　除了这些给出的限制，任何假定的差异，若用于汽车时速，每小时消耗大量的卡路里，或者一个浏览器如何快速地渲染，都会让它吃不少苦头。在这里，可信区间给你一个指标去信任这些样本值的差异度，不多也不少。

　　基于Javascript的性能测试

　　第一个是对DOM(浏览器的文档对象模型)的压力测试。用1像素的单位来填充一个单独的DIV(布局)，既精确又密集。这里有两个设定，基准和满载，分别是用3个像素和1个像素的DIVs。下图是基准测试的结果。

　　像素填充测试结果

　　当进行满载测试时，59000个DIVs被动态创建，完全测试了DOM，IE7在满分辨率下无法渲染所有的像素；尽管Opera Merlin(Opera的上一个渲染引擎)快速地渲染，但也处于高度不稳定的状态。所以我们只采纳Safari 3, Opera Kestrel and Firefox 3的结果,如下图所示：

　　Safari 3, Opera 9.5 和 Firefox 3

　　最后，在满载情况下进行渲染测试时，当所有的DIVs都成功创建后，我好奇地查看了内存占用，在展开一个庞大的DOM时，Kerstrel的内存使用率最少。

　　内存使用率的对比

　　网络传输

　　这是来自Webkit Wiki的数据，是使用ECMAScript进行的纯模拟计算，数据如下图：

　　ECMAScript进行的纯模拟计算

　　3D立方体

　　这里有另一个同时对ECMAScript引擎和常规显示做的测试；它模拟生成一个实时旋转的3D形状的盒子。这里有两种，小型的和大型的；我展示生成大型3D盒子的结果在这里，这些是在每个循环里所花费的平均时间（随着时间的消逝，变化会更大）。在OS X平台上Opera Merlin和Opera Kestrel的结果也一起标明了。Mac用户已经感觉到Mac平台上的Opera比Windows平台上的相同版本慢一些。这次的测试证明了，对于Mac平台上的Opera Merlin来说，这个结论的确是真实的。但同时也看出来，对于Kestrel来说，平台间的差异是非常小的。

　　3D立方体测试

　　DOM核心性能测试

　　从Ian Hickson（编者注：一个人名）的性能测试那里拿来的结果，这里测试了一些DOM核心操作。

　　DOM核心性能测试结果

　　DOM动画测试

　　同样是来自Ian Hickson的性能测试。这里有4个版本，一个使用表格，一个使用壁纸，另两个使用不同检索方式的布局。这个测试含有，实时绘制一系列的图形来建构一个动画，而这并没有使用任何实际的图形，所以它用像素数据来构建图形（存放在一个javascript的数组里），用DHTML来动态执行这个动画。对于DOM和显示来说，这是非常精确的，结果是它尽可能地渲染以达到每秒最大数目的帧数（FP/S）。为求简便，我没有显示错误信息。但要记得，Opera Kestrel的99.9%的可信区间分别在±0.19, ±1.4, ±0.12 & ±0.25里。

　　DOM动画测试

　　IE7在前两个测试中失败了，而在后两个测试里“表现惊人”。对于布局1,在测试开始的时候它CPU占用率一直是100%，然后正常渲染——我列入结果的时间是已经冻结后的，所以这是公平的。

　　在这些测试进行的时候查看CPU占用也是有启发性的，我会选择布局2是因为它使用标准的DOM方法来索引这些布局（使用CPU的时间是通过Sysinternals网站上的一个Process Explorer 进程查看工具来测量的）。

　　CPU使用率测试

　　页面装载速度测试　（注：测试时间单位是毫秒 ms）

　　对渲染核心逐项进行压力测试是非常有益的，但问题是，它处理实际页面的时候怎样？答案是复杂的。

　　首先，互联网上的不可靠因素比较多，当读取一个页面时，速度的快慢可能并不取决于你的电脑配置的高低。其次，广告服务器对于每一次请求都返回不同的内容，所以不可能进行确定的比较。基于以上这两条理由，如果你对渲染速度很感兴趣，我们必须排除这些混杂因素的干扰。可以通过使用本地服务器（接近在同一个本地网络上的实验机），保存在互联网上获取的页面，包括全部图片，样式表，Javascript效果，同时移除所有对外部服务器的请求。为了能够在一个稳定的环境下来测试渲染性能，我在装载页面的时候利用一个框架来自动实现这点。我已经这样做了，实验对象是Digg.com网站，纽约时报网站首页(nytimes.com)以及英国广播公司网站首页(bbcnews.com)。

　　Digg.com页面装载速度

　　纽约时报网站首页装载速度

　　英国广播公司网站首页装载速度

　　最终得出结论：

　　从总的情况来看，Opera Kestrel已经比Opera Merlin快上很多，其他浏览器的一般外部测试也进行了。从满载情况下对Javascript的充分的性能追踪得出结论，Opera Kestrel性能更加地稳定和更高效地内存使用率。这一点是重要的，因为Opera在所有的设备上使用同样的核心，例如在移动电话，游戏机控制台，和个人电脑上都一样。拥有一个高效的内核，更低的资源占用率，更好的跨设备平台适应性，Opera Kestrel看上去已经在渲染速度上达到了一个新的标准。

　　对于Mac用户来说，同样有一个好消息，因为Mac平台上的Opera Kestrel已经非常接近Windows版本了（在某些情况下几乎一样快）。

　　Safari没有出现在上面的图表里是因为它返回装载事件比其他浏览器都快（在页面装载完成前），所以没法进行比较，其页面装载的性能测试直接依靠浏览器装载事件(onload)的返回来进行衡量。而在OS X平台上的Safari浏览器拥有一个页面装载计时器，就在它的调试目录里，所以我能告诉你，Safari打开Digg.com网站首页用了495ms，打开纽约时报网站首页(nytimes.com)用了298ms，打开英国广播公司新闻网站(bbcnews.com)用了201ms。但是它并没有给出标准偏差用来确定误差率，所以，它看起来和Opera Kestrel一样地快。