JS教程:为什么尽量用局部变量代替全局变量
| ecution Context）的作用域链中进行搜索。从作用域链的第一个对象（该函数的Activation Object对象）开始，如果没有找到，就搜索作用域链中的下一个对象，如此往复，直到找到了标识符的定义。如果在搜索完作用域中的最后一个对象，也就是全局对象（Global Object）以后也没有找到，则会抛出一个错误，提示用户该变量未定义（undefined）。这是在ECMA-262标准中描述的函数执行模型和标识符解析（Identifier Resolution）的过程，事实证明，大部分的JavaScript引擎确实也是这样实现的。需要注意的是，ECMA-262并没有强制要求采用这种结构，只是对这部分功能加以描述而已。
了解标识符解析（Identifier Resolution）的过程以后，我们就能明白为什么局部变量的解析速度要比其他作用域的变量快，主要是由于搜索过程被大幅缩短了。但是，具体会快多少呢？为了回答这个问题，我模拟了一系列的测试，来测试不同作用域深度中变量的性能。 第一个测试是向一个变量中写入一个最简单的值（这里使用字面量的数值1），结果如下图显示，很有趣：
从结果中不难看出，当标识符解析的过程需要进行深度搜索时，会伴随性能损失，而且性能损失的程度会随着标识符深度的增加而递增。意料之中的是，Internet Explorer表现的是最差的（但公平的说，IE 8还是有一些改善的）。值得注意的是，这里有一些例外情况，Google Chrome和最新的WebKit午夜版在访问变量的时间保持得很稳定，不会随着作用域深度的递增而增长。当然，这应该归功于它们所使用的下一代 JavaScript引擎，V8和SquirrelFish。这些引擎在执行代码时进行了优化，而且很明显，这些优化使访问变量的速度比以往更快。 Opera表现的也很不错，比IE、Firefox和当前版本的Safari要快的多，但比基于V8和Squirrelfish的浏览器要慢。 Firefox 3.1 Beta 2的表现有点出人意料，对于局部变量执行的效率非常高，但随着作用域层数的增加，效率便大打折扣。需要注意的是，我这里使用的都是默认设置，也就是说 Firefox是没有开启Trace功能的。 上面的结果是通过对变量执行写操作而得出的，其实我很好奇，读取变量时的情况会不会有什么不同，于是接着做了下面的测试。结果发现，读的速度要比写的速度快一些，但是性能变化的趋势是一致的。
和上个测试一样，Internet Explorer和Firefox还是最慢的，Opera表现了非常抢眼的性能，而同样的，Chrome和最新版本的Webkit午夜版显示了和作用域深度无关的性能趋势，同样需要注意的是，Firefox |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
