SunSpider基准测试表明，现在移动Web应用的运行速度普遍较慢（如图1所示）。 基本上，人们对于SunSpider基准测试的态度主要有以下三类。
JavaScript比原生代码慢已不是什么新闻，现在的问题是，JavaScript在某些方面有点慢，对于你正在编写的软件类型是否至关重要。
JavaScript的运行速度对程序确实有所影响，但它正变得越来越快，总会有一天会甩掉“慢”的帽子。
我用Python/PHP/Ruby来编写服务器端代码，我的服务器比你们的移动设备运行速度快。但假如我用解释型语言可以很好地支持上千个左右的用户，你们肯定能想出使用高性能的JIT语言支持单个用户的方法吗？这样做的难度有多大？
图1 JavaScript程序在不同浏览器上的运行速度
在本篇文章中，我会做一个大胆的尝试——反驳上述的三个观点。JavaScript运行起来的确很慢，而且将来也没有变快的倾向；在服务器端编程的经验看似很牛，但当你试图思考移动应用的性能时，却使你无法“从小处着眼”。此外，在谈及JavaScript的文章中，很少有人真正量化它到底有多慢，或提供一套评判标准。为了纠正这一点，我会为JavaScript的性能提供三个当量，让大家对它有一个直观的认知。
与原生程序的性能进行相比，JS的表现究竟如何？
为了回答这个问题，我从Benchmarks Game中任意选取了一个基准测试。然后，找了一个很老的执行这个测试的C语言程序。我用iPhone 4S对LLVM（底层虚拟机）和Nitro进行对比测试。测试中，LLVM的速度始终是Nitro的4.5倍（如图2所示）。
由于现实中运行的代码都是任意的，所以这类实验才很有价值，你也不妨亲自做一做这样的实验。如果你好奇“如果CPU绑定函数不在Nitro JS中，而是放在原生代码中，速度会快多少”，我的回答是快5倍左右。这个答案与Benchmarks Game测试x86/GCC/V8的结果大体一致（GCC/x86一般比V8/x86快2~9倍）。
图2 LLVM与Nitro对比测试的结果
只有原生代码1/5的表现，是否能满足所有人？
密集型CPU是如何渲染电子表格的？其实没那么难。问题是，ARM不是x86。根据GeekBench的测试结果显示，最新的MBP与最新的iPhone相比，全系数差异为10，所以电子表格的渲染是没什么问题的。但文字处理的情况又怎么样呢？我们难道不能像在m68k（摩托罗拉68000的CPU）上那样，通过在其后面绑定一个协同处理器来操作吗？你也许忘了，Google Docs的实时协作功能，其实不是它的一种特性，这项功能是在2010年4月大规模改写时添加进来的。有了这项功能，iPhone 4S相对于Web浏览器完全没有竞争力。
让我们再来看看另一个重要的JavaScript应用程序——Google Wave。Google Wave从来不支持 IE8，因为IE8太慢了。所有受支持Google Wave的浏览器（Gogle Chrome、Safari 4、Firefox）的基准测试结果都低于1000毫秒。而iPhone的基准测试结果是2400毫秒，因此，它无法运行Google Wave。这里要说明一点：实时协作可以在移动设备上执行，却不可以用JavaScript执行。原生应用和Web应用之间的性能差距与FireFox和IE8之间的性能差距相当，对于重要的工作来说，这个差距相当大了。
本栏目更多精彩内容：http://www.bianceng.cn/webkf/tools/