在1996年,JavaScript引擎只要能支持页面里数十行的JavaScript代码就好,而今天,却运行着成千上万行JavaScript代码的Web应用。从许多方面来说,如果不是因为浏览器自身在语言管理和基础设施方面的落后,JavaScript本可能取得更大规模的成功。IE6就是一个明证,发布之初,它的稳定性和性能都被人们称颂,但后来却因为自身的Bug和反应迟钝而被痛批为令人讨厌的Web应用平台。<br> 事实上,IE6并没有变慢,它只是被寄予了厚望。2001年IE 6刚发布时出现的各类早期Web应用比2005年后出现的应用更轻量,JavaScript代码也远没有那么多。JavaScript代码数量的增长带来的影响变得明显,IE 6的JavaScript引擎吃不消了,原因在于它的“静态垃圾回收机制”。该引擎监视内存中固定数量的对象来确定何时进行垃圾回收。早期的Web应用开发人员很少会遇到这个极限值,随着更多的JavaScript代码产生越来越多的对象,复杂的Web应用开始频繁遭遇这个门槛。问题变得清晰起来:JavaScript开发人员和Web应用都在发展,而JavaScript引擎却没有。<br> 尽管其他浏览器。有着更加完善的垃圾回收机制和更好的运行性能,但大多数仍然使用JavaScript解释器来执行代码。解释性代码天生就没有编译性代码快,因为解释性代码必须经历把代码转化成计算机指令的过程。无论解释器怎样优化和多么智能,它总是会带来一些性能损耗。<br> 编译器已经有了各种各样的优化,使得开发人员可以按照他们想要的方式编写代码,而不需要担心是否是最优。编译器可以基于词法分析去判断代码想实现什么,然后产生出能完成任务的运行最快的机器码来进行优化。解释器很少有这样的优化,这很大程度上意味着,代码怎么写,就被怎么执行。<br> 实际上,通常在其他语言中由编译器处理的优化,在JavaScript中却要求开发人员来完成。<br> ……
展开