客户端应用程序的日益丰富越来越显示出JavaScript的性能劣势，由于这种语言太大的灵活性，大多数实现都是解释器类型，性能都不会太好，人们甚至怀疑基于JavaScript的重量级web应用是否还有前途。好消息是Google Chrome的JavaScript引擎是一个虚拟机叫做v8，Firefox 3.1将会把原来的SpiderMonkey替换为更强大的TraceMonkey，一个应用JIT技术的引擎。
但是Chrome才刚刚出现，Firefox所占的市场份额也还不足够让人把它当作准绳。我们时时得考虑古老、陈旧、笨重的Internet Explorer，至少我们还没看见IE8的JavaScript实现有任何值得欢呼的线索。
即使所有浏览器都有了高效的实现，注重代码本身的性能依旧是一个好的习惯。写出优质的代码，比把劣质的代码扔给编译器/解释器去优化好得多，即使编译器/解释器的优化很强大，因为起点不一样。
下面是一些对了解JavaScript性能有帮助的一些资源：
- IE Blog里关于JS性能的文章，我建议新手先不要看IE/JScript Blog里的东西，他们经常会拿出自家的一些私藏来招待你。是的，IE没有实现JavaScript，他们实现的是一个叫JScript的东西，看起来跟JavaScript有点像。
IE + JavaScript Performance Recommendations – Part 1 变量使用的建议，你会看到，解释器不会做一丁点的优化，一些看似无用的多余代码可能会帮助你改善性能。
Part 2: JavaScript Code Inefficiencies 关于字符串拼接，eval和switch.
Part 3 提到一点内存泄漏问题。 - jQuery的作者指出提高客户端性能的工作不仅存在于JavaScript本身。
JavaScript Performance Stack - When innerHTML isn’t Fast Enough 我们知道如果有一大堆HTML要插入DOM，innerHTML方式要比document.createElement然后插入快得多。这篇文章给出一种比innerHTML更快的方式。
- Comet Information Systems写的系列文章：
String Manipulation 字符串拼接
DOM Manipulation innerHTML, createElement, cloneNode.
General Tips - 对于编译器来说，循环不变量外提是最基本的优化之一，然而你可不要认为JavaScript解释器也会为你做这个：
JavaScript loop performance - 微软曾经针对IE推出一个自动更新，声称内存泄漏得到了解决，一时间开发者们欢欣鼓舞。但是马上人们就发现了问题，和他们在blog里的惯用手法一样，这只不过是掩人耳目，夸大其词。
Leave a Reply