小议Javascript代码优化方法及原则

Javascript优化已经讨论了很多了&＃xff0c;最近也频繁接触Javascript
代码&＃xff0c;对Javascript优化也有一些自己的想法&＃xff0c;写出一个健壮、高效的
代码是每个设计者的最终目标,酒窝最近遇到的一些问题,这里我想从更基础的角度总结在Web开发中Javascript优化的几个原则及方法。



原则一&＃xff0c;为IE6&＃xff08;未打补丁的JScript 5.6或更早版本&＃xff09;做优化&＃xff01;

与其他语言不同&＃xff0c;JS的效率很大程度是取决于JS engine的效率。除了引擎实现的优劣外&＃xff0c;引擎自己也会为一些特殊的代码模式采取一些优化的策略。例如FF、Opera和Safari的JS引擎&＃xff0c;都对字符串的拼接运算&＃xff08;&＃43;&＃xff09;做了特别优化。显然&＃xff0c;要获得最大效率&＃xff0c;就必须要了解引擎的脾气&＃xff0c;尽量迎合引擎的口味。所以对于不同的引擎&＃xff0c;所作的优化极有可能是背道而驰的。

而如果做跨浏览器的web
编程&＃xff0c;则最大的问题是在于IE6&＃xff08;JScript 5.6&＃xff09;&＃xff01;因为在不打hotfix的情况下&＃xff0c;JScript引擎的垃圾回收的bug&＃xff0c;会导致其在真实应用中的performance跟其他浏览器根本不在一个数量级上。因此在这种场合做优化&＃xff0c;实际上就是为JScript做优化&＃xff01;



原则二&＃xff0c;是以大规模循环体为最主要优化对象。

如果你的程序已经优化到在IE6下可以接受的性能&＃xff0c;那基本上在其他浏览器上性能就完全没有问题。

因此&＃xff0c;注意我下面讲的许多问题在其他引擎上可能完全不同&＃xff0c;例如在循环中进行字符串拼接&＃xff0c;通常认为需要用Array.join的方式&＃xff0c;但是由于SpiderMonkey等引擎对字符串的“&＃43;”运算做了优化&＃xff0c;结果使用Array.join的效率反而不如直接用“&＃43;”&＃xff01;但是如果考虑IE6&＃xff0c;则其他浏览器上的这种效率的差别根本不值一提。

JS优化与其他语言的优化也仍然有相同之处。比如说&＃xff0c;不要一上来就急吼吼的做优化&＃xff0c;那样毫无意义。优化的关键&＃xff0c;仍然是要把精力放在最关键的地方&＃xff0c;也就是瓶颈上。一般来说&＃xff0c;瓶颈总是出现在大规模循环的地方。这倒不是说循环本身有性能问题&＃xff0c;而是循环会迅速放大可能存在的性能问题。



原则三&＃xff0c;尽量避免过多的引用层级和不必要的多次方法调用(注:以下的优化原则&＃xff0c;只在大规模循环中才有意义&＃xff0c;在循环体之外做此类优化基本上是没有意义的)

目前绝大多数JS引擎都是解释执行的&＃xff0c;而解释执行的情况下&＃xff0c;在所有操作中&＃xff0c;函数调用的效率是较低的。此外&＃xff0c;过深的prototype继承链或者多级引用也会降低效率。JScript中&＃xff0c;10级引用的开销大体是一次空函数调用开销的1/2。这两者的开销都远远大于简单操作&＃xff08;如四则运算&＃xff09;。



原则四&＃xff0c;尽量使用语言本身的构造和内建函数。

特别要注意的是&＃xff0c;有些情况下看似是属性访问&＃xff0c;实际上是方法调用。例如所有DOM的属性&＃xff0c;实际上都是方法。在遍历一个NodeList的时候&＃xff0c;循环条件对于nodes.length的访问&＃xff0c;看似属性读取&＃xff0c;实际上是等价于函数调用的。而且IE DOM的实现上&＃xff0c;childNodes.length每次是要通过内部遍历重新计数的。&＃xff08;My god&＃xff0c;但是这是真的&＃xff01;因为我测过&＃xff0c;childNodes.length的访问时间与childNodes.length的值成正比&＃xff01;&＃xff09;这非常耗费。所以预先把nodes.length保存到js变量&＃xff0c;当然可以提高遍历的性能。

同样是函数调用&＃xff0c;用户自定义函数的效率又远远低于语言内建函数&＃xff0c;因为后者是对引擎本地方法的包装&＃xff0c;而引擎通常是c,c&＃43;&＃43;,
php?name&＃61;java" οnclick&＃61;"tagshow(event)" class&＃61;"t_tag">java写的。进一步&＃xff0c;同样的功能&＃xff0c;语言内建构造的开销通常又比内建函数调用要效率高&＃xff0c;因为前者在JS代码的parse阶段就可以确定和优化。



这里有一个例子是高性能的String.format方法。String.format传统的实现方式是用String.replace(regex, func)&＃xff0c;在pattern包含n个占位符&＃xff08;包括重复的&＃xff09;时&＃xff0c;自定义函数func就被调用n次。而这个高性能实现中&＃xff0c;每次format调用所作的只是一次Array.join然后一次String.replace(regex, string)的操作&＃xff0c;两者都是引擎内建方法&＃xff0c;而不会有任何自定义函数调用。两次内建方法调用和n次的自定义方法调用&＃xff0c;这就是性能上的差别。

同样是内建特性&＃xff0c;性能上也还是有差别的。例如在JScript中对于arguments的访问性能就很差&＃xff0c;几乎赶上一次函数调用了。因此如果一个可变参数的简单函数成为性能瓶颈的时候&＃xff0c;可以将其内部做一些改变&＃xff0c;不要访问arguments&＃xff0c;而是通过对参数的显式判断来处理。

比如&＃xff1a;

代码

1.        function sum() {   

2.            var r &＃61; 0;   

3.            for (var i &＃61; 0; i
4.                r &＃43;&＃61; arguments
;   
5.            }   
6.            return r;   
7.        }   

这个sum通常调用的时候个数是较少的&＃xff0c;我们希望改进它在参数较少时的性能。如果改成&＃xff1a;

代码

1.        function sum() {   

2.            switch (arguments.length) {   

3.                case 1: return arguments[0];   

4.                case 2: return arguments[0] &＃43; arguments[1];   

5.                case 3: return arguments[0] &＃43; arguments[1] &＃43; arguments[2];   

6.                case 4: return arguments[0] &＃43; arguments[1] &＃43; arguments[2] &＃43; arguments[3];   

7.                default:   

8.                    var r &＃61; 0;   

9.                    for (var i &＃61; 0; i
10.                        r &＃43;&＃61; arguments;   

11.                    }   

12.                    return r;   

13.            }   

14.        }   



其实并不会有多少提高&＃xff0c;但是如果改成&＃xff1a;

代码

1.        function sum(a, b, c, d, e, f, g) {   

2.            var r &＃61; a ? b ? c ? d ? e ? f ? a &＃43; b &＃43; c &＃43; d &＃43; e &＃43; f : a &＃43; b &＃43; c &＃43; d &＃43; e : a &＃43; b &＃43; c &＃43; d : a &＃43; b &＃43; c : a &＃43; b : a : 0;   

3.            if (g &＃61;&＃61;&＃61; undefined) return r;   

4.            for (var i &＃61; 6; i
5.                r &＃43;&＃61; arguments;   

6.            }   

7.            return r;   

8.        }   



就会提高很多&＃xff08;至少快1倍&＃xff09;。



原则五&＃xff0c;尽量减少不必要的对象创建。

本身创建对象是有一定的代价的&＃xff0c;但是这个代价其实并不大。最根本的问题是由于JScript愚蠢之极的垃圾回收调度
算法&＃xff0c;导致随着对象个数的增加&＃xff0c;性能严重下降&＃xff08;据微软的人自己说复杂度是O(n^2)&＃xff09;。

比如我们常见的字符串拼接问题&＃xff0c;经过我的测试验证&＃xff0c;单纯的多次创建字符串对象其实根本不是性能差的原因。要命的是在对象创建期间的无谓的垃圾回收的开销。而Array.join的方式&＃xff0c;不会创建中间字符串对象&＃xff0c;因此就减少了那该死的垃圾回收的开销。

因此&＃xff0c;如果我们能把大规模对象创建转化为单一语句&＃xff0c;则其性能会得到极大的提高&＃xff01;例如通过构造代码然后eval——实际上PIES项目中正在根据这个想法来做一个专门的大规模对象产生器……

好了上面就是偶总结的JS优化五大原则。

除了这些原则以外&＃xff0c;还有一些特殊情况&＃xff0c;如DOM的遍历&＃xff0c;以后有时间再做讨论。