性能测试和调优

这一趴我还觉得蛮有趣的。更新了我的知识库。

性能测试和调优的目的不是为了满足 对微观性能调优的沉迷，比如某个 JavaScript 引擎上运行 ++a 是不是会比 a++ 快。本章更 重要的目标是弄清楚哪些种类的 JavaScript 性能更重要，哪些种类则无关紧要，以及如何 区分。

常规的做法是：

var start = (new Date()).getTime(); // 或者Date.now()  
 
// 进行一些操作  
 
var end = (new Date()).getTime();  
 
 console.log( "Duration:", (end - start) ); 

平台的精度有关

报告的时间是 0，可能你会认为它的执行时间小于 1ms。但是，这并不十分精确。有 些平台的精度并没有达到 1ms，比如，Windows（也 就是 IE）的早期版本上的精度只有 15ms，这就意味着这个运算的运行时间至少需要这么 长才不会被报告为 0 ！

测试环境是否优化

更麻烦的是，你也不知道这个运算测试的环境是否过度优化了。有可能 JavaScript 引擎找 到了什么方法来优化你这个独立的测试用例，但在更真实的程序中是无法进行这样的优化 的，那么这个运算就会比测试时跑得慢。

引擎或者系统是否受到影响

不管报告的时长是多少，你能知道的唯一一点就是，这个运算的这次特定的运行消 耗了大概这么长时间。而它是不是总是以这样的速度运行，你基本上一无所知。你不知道 引擎或系统在这个时候有没有受到什么影响，以及其他时候这个运算会不会运行得更快。

数学平均可能会让某一次的误差扩散

简单的数学平均值绝对不足以对你要外推到整个应用范围的性能作出判断。迭代 100 次， 即使只有几个（过高或过低的）的异常值也可以影响整个平均值，然后在重复应用这个结 论的时候，你还会扩散这个误差，产生更大的欺骗性。

 

有些区别太小，以至于没必要

如果 X 需要 100ns，而 Y 需要 80ns，那么差别就是 20ns，这在最好情况下也只是人类大脑 所能感知到的最小间隙的 65 万分之一。

引擎优化
有时候引擎会因为固定输入而产生了优化。但是在真实的程序中输入并不一定是固定的。

多环境测试

// 用例1 
 var x = false;  var y = x ? 1 : 2;  
 
// 用例2  
var x = undefined;  var y = x ? 1 : 2;
用例2实际上还有一个类型转换的过程；

如果你想要得到可靠的测试结论的话，就需要在很多不同的环境（桌面浏览 器、移动设备，等等）中测试汇集测试结果；

高端桌面机器的性能很可能和智能手机上 Chrome 移动设备完全不 同。而电量充足的智能手机上的结果可能也和同一个智能手机但电量只有 2% 时完全不同， 因为这时候设备将会开始关闭无线模块和处理器。
 

测试是不是对等

// 用例1  
var x = false;  var y = x ? 1 : 2;  
 
// 用例2 
 var x;  var y = x ? 1 : 2; 

用例2 还涉及到类型转换；

 

优化关注点

花费在优化关键路径上的时间不是浪费，不管节省的时间多么 少；而花在非关键路径优化上的时间都不值得，不管节省的时间多么多。

如果你的代码在关键路径上，比如是一段将要反复运行多次的“热”代码，或者在用户会 注意到的 UX 关键位置上，如动画循环或 CSS 风格更新，那你就不应该吝惜精力去采用有 意义的、可测量的有效优化。

 

尾递归优化

es6的一个内容。