你不知道的JS（中）：程序性能与测试
本文是《你不知道的JavaScript（中卷）》的阅读笔记，第四部分：程序性能与测试。 供自己以后查漏补缺，也欢迎同道朋友交流学习。
程序性能
异步对 JavaScript 来说真的很重要，最显而易见的原因就是性能。如果要发出两个 Ajax 请求，并且它们之间是彼此独立的，但是需要等待两个请求都完成才能执行下一步的任务，那么为这个交互建模有两种选择：顺序与并发。 通常后一种模式会比前一种更高效。而更高的性能通常也会带来更好的用户体验。
Web Worker
我们已经详细介绍了 JavaScript 是如何单线程运作的。但是，单线程并不是组织程序执行的唯一方式。 设想一下，把你的程序分为两个部分：一部分运行在主 UI 线程下，另外一部分运行在另一个完全独立的线程中。
你的浏览器这样的环境，很容易提供多个 JavaScript 引擎实例，各自运行在自己的线程上，这样你可以在每个线程上运行不同的程序。程序中每一个这样的独立的多线程部分被称为一个（Web）Worker。这种类型的并行化被称为任务并行，因为其重点在于把程序划分为多个块来并发运行。
从 JavaScript 主程序（或另一个 Worker）中，可以这样实例化一个 Worker：
// 主程序
var w1 = new Worker( "http://some.url.1/mycoolworker.js" );
// 监听事件
w1.addEventListener( "message", function(evt){
// evt.data
} );
// 发送事件
w1.postMessage( "something cool to say" );
worker内部，收发消息是完全对称的：
// "mycoolworker.js"
addEventListener( "message", function(evt){
// evt.data
} );
postMessage( "a really cool reply" );
1. Worker环境 在 Worker 内部是无法访问主程序的任何资源的。这意味着你不能访问它的任何全局变量，也不能访问页面的 DOM 或者其他资源。记住，这是一个完全独立的线程。
但你可以执行网络操作Ajax、WebSockets以及设定定时器。还有Worker可以访问几个重要的全局变量和功能的本地复本，包括 navigator、location、JSON 和 applicationCache。
你还可以通过 importScripts(..) 向 Worker 加载额外的 JavaScript 脚本：
// 在Worker内部
importScripts( "foo.js", "bar.js" );
这些脚本加载是同步的。也就是说，importScripts(..) 调用会阻塞余下 Worker 的执行，直到文件加载和执行完成。
Web Worker 通常应用于哪些方面呢？
- 处理密集型数学计算
- 大数据集排序
- 数据处理（压缩、音频分析、图像处理等）
- 高流量网络通信
2. 数据传递 在线程之间通过事件机制传递大量的信息，可能是双向的。 特别是对于大数据集而言，就是使用 Transferable 对象。这时发生的是对象所有权的转移，数据本身并没有移动。一旦你把对象传递到一个 Worker 中，在原来的位置上，它就变为空的或者是不可访问的，这样就消除了多线程编程作用域共享带来的混乱。当然，所有权传递是可以双向进行的。
// 比如foo是一个Uint8Array
postMessage( foo.buffer, [ foo.buffer ] );
3. 共享Worker 创建一个整个站点或 app 的所有页面实例都可以共享的中心 Worker 就非常有用了。这称为 SharedWorker，可通过下面的方式创建（只有 Firefox 和 Chrome 支持这一功能）：
var w1 = new SharedWorker( "http://some.url.1/mycoolworker.js" );
在共享 Worker 内部，必须要处理额外的一个事件："connect"。这个事件为这个特定的连接提供了端口对象。保持多个连接独立的最简单办法就是使用 port 上的闭包：
// 在共享Worker内部
addEventListener( "connect", function(evt){
// 这个连接分配的端口
var port = evt.ports[0];
port.addEventListener( "message", function(evt){
// ..
port.postMessage( .. );
// ..
} );
// 初始化端口连接
port.start();
} );
SIMD
单指令多数据（SIMD）是一种数据并行（data parallelism）方式，与 Web Worker 的任务并行（task parallelism）相对，因为这里的重点实际上不再是把程序逻辑分成并行的块，而是并行处理数据的多个位。
asm.js
asm.js这个标签是指 JavaScript 语言中可以高度优化的一个子集。通过小心避免某些难以优化的机制和模式（垃圾收集、类型强制转换，等等），asm.js 风格的代码可以被 JavaScript 引擎识别并进行特别激进的底层优化。
1. 如何使用：
var a = 42;
var b = a | 0;
此处我们使用了与 0 的 |（二进制或）运算，除了确保这个值是 32 位整型之外，对于值没有任何效果。这样的代码在一般的 JavaScript 引擎上都可以正常工作。 而对支持 asm.js 的JavaScript 引擎来说，这段代码就发出这样的信号，b 应该总是被当作 32位整型来处理，这样就可以省略强制类型转换追踪。
2. asm.js 模块 对一个 asm.js 模块来说，你需要明确地导入一个严格规范的命名空间——规范将之称为stdlib，因为它应该代表所需的标准库。 你还需要声明一个堆（heap）并将其传入。这个术语用于表示内存中一块保留的位置，变量可以直接使用而不需要额外的内存请求或释放之前使用的内存。这样，asm.js 模块就不需要任何可能导致内存扰动的动作了，只需使用预先保留的空间即可。
var heap = new ArrayBuffer( 0x10000 ); // 64k堆
var arr = new Float64Array( heap );
asm.js 代码如此高度可优化的那些限制的特性显著降低了这类代码的使用范围。asm.js 并不是对任意程序都适用的通用优化手段。它的目标是对特定的任务处理提供一种优化方法，比如数学运算（如游戏中的图形处理）。
程序性能小结
异步编码模式使我们能够编写更高效的代码，通常能够带来非常大的改进。但是，异步特性只能让你走这么远，因为它本质上还是绑定在一个单事件循环线程上。 因此，在这一章里，我们介绍了几种能够进一步提高性能的程序级别的机制。
性能测试与调优
性能测试
如果被问到如何测试某个运算的速度（执行时间），绝大多数 JavaScript 开发者都会从类似下面的代码开始：
var start = (new Date()).getTime(); // 或者Date.now()
// 进行一些操作
var end = (new Date()).getTime();
console.log( "Duration:", (end - start) );
这样低可信度的测试几乎无力支持你的任何决策。这个性能测试基本上是无用的。更坏的是它是危险的，因为它可能提供了错误的可信度。
1. 重复 你可以不以固定次数执行运算，转而循环运行测试，直到达到某个固定的时间。这可能会更可靠一些。
2. Benchmark.js 一个统计学上有效的性能测试工具，名为 Benchmark.js，我们使用这个工具就好了。
环境为王
对特定的性能测试来说，不要忘了检查测试环境，特别是比较任务 X 和 Y 这样的比对测试。仅仅因为你的测试显示 X 比 Y 快，并不能说明结论 X 比 Y 快就有实际的意义。
引擎优化 现代引擎要比我们凭直觉进行的推导复杂得多。它们会实现各种技巧，比如跟踪记录代码在一小段时期内或针对特别有限的输入集的行为。
jsPerf.com
如果想要在不止一个环境下得出像“X 比 Y 快”这样的有意义的结论成立，那你需要在尽可能多的真实环境下进行实际测试。仅仅因为在 Chrome 上某个 X 运算比 Y 快并不意味着这在所有的浏览器中都成立。当然你可能还想要交叉引用多个浏览器上的测试运行结果，并有用户的图形展示。 有一个很棒的网站正是因这样的需求而诞生的，名为 jsPerf (jsperf.com)。它使用我们前面介绍的 Benchmark.js 库来运行统计上精确可靠的测试，并把测试结果放在一个公开可得的 URL 上，你可以把这个 URL 转发给别人。
写好测试
编写更好更清晰的测试。
微性能
var x = [ .. ];
// 选择1
for (var i=0; i < x.length; i++) {
// ..
}
// 选择2
for (var i=0, len = x.length; i < len; i++) {
// ..
}
理论上说，这里应该在变量 len 中缓存 x 数组的长度，因为表面上它不会改变，来避免在每个循环迭代中计算 x.length 的代价。
如下是 v8 的一些经常提到的例子：
- 不要从一个函数到另外一个函数传递 arguments 变量，因为这样的泄漏会降低函数实现速度.
- 把 try..catch 分离到单独的函数里。浏览器对任何有 try..catch 的函数实行优化都有一些困难，所以把这部分移到独立的函数中意味着你控制了反优化的害处，并让其包含的代码可以优化。
尾调用优化
ES6 包含了一个性能领域的特殊要求。这与一个涉及函数调用的特定优化形式相关：尾调用优化（Tail Call Optimization，TCO）。
function foo(x) {
return x;
}
function bar(y) {
return foo( y + 1 ); // 尾调用
}
function bar(y) {
return foo( y + 1 ); // 尾调用
}
function baz() {
return 1 + bar( 40 ); // 非尾调用
}
baz(); // 42
调用一个新的函数需要额外的一块预留内存来管理调用栈，称为栈帧。所以前面的代码一般会同时需要为每个 baz()、bar(..) 和 foo(..) 保留一个栈帧。 然而，如果支持 TCO 的引擎能够意识到 foo(y+1) 调用位于尾部，这意味着 bar(..) 基本上已经完成了，那么在调用 foo(..) 时，它就不需要创建一个新的栈帧，而是可以重用已有的 bar(..) 的栈帧。这样不仅速度更快，也更节省内存。
性能测试与调优小结
尾调用优化是 ES6 要求的一种优化方法。它使 JavaScript 中原本不可能的一些递归模式变得实际。TCO 允许一个函数在结尾处调用另外一个函数来执行，不需要任何额外资源。这意味着，对递归算法来说，引擎不再需要限制栈深度。
