作者：Alon Zakai <br/>
编译：胡子大哈
翻译原文：http://huziketang.com/blog/posts/detail?postId=58d11a9aa6d8a07e449fdd2a <br/>
英文原文：High-performance ES2015 and beyond
转载请说明出处，保留原文链接以及作者信息
过去几个月 V8 团队聚焦于提拔新增的 ES2015 的一些机能、提拔近来一些其他 JavaScript 新特征的机能，使其能够到达或逾越响应的 ES5 的机能。
起点
在我们议论这些差别的革新之前，要先相识在当前的 Web 开辟中，已有了广为运用的 Babel 作为编译器，为何还要斟酌 ES2015+ 的机能题目：
起首，有一些新的 ES2015 特征是只要 polyfill 时须要的。比方
Object.assign函数。当 Babel 转译 “object spread property” 的时刻（在 React 和 Redux 中常常遇到），就会依靠Object.assign来替换 ES5 中响应的函数（假如VM环境支撑的话）。polyfill ES2015 的新特征往往会增添代码的 size，这些 ES2015 特征却有助于减缓当前的 web 机能危急，特别像在手机装备如许的新兴市场上。在如许一种状况下，代码的剖析和的本钱将会很高。
末了，客户端的 JavaScript 运转环境只是依靠于 V8 引擎的环境之一，另有服务端的 Node.js 运用和东西等，它们都不须要转译成 ES5 代码，而直接运用最新的 V8 版本就能够运用这些新特征了。
一同来看一下下面这段 Redux 文档中的代码：
function todoApp(state = initialState, action) {
switch (action.type) {
case SET_VISIBILITY_FILTER:
return { ...state, visibilityFilter: action.filter }
default:
return state
}
}
有两个处所须要转译：默许参数 state 和 state 作为实例化对象举行返回。Babel 将天生以下 ES5 代码：
"use strict";
var _extends = Object.assign || function (target) {
for (var i = 1; i < arguments.length; i++) {
var source = arguments[i];
for (var key in source) {
if (Object.prototype.hasOwnProperty.call(source, key)){
target[key] = source[key];
}
}
}
return target;
};
function todoApp() {
var state = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : initialState;
var action = arguments[1];
switch (action.type) {
case SET_VISIBILITY_FILTER:
return _extends({}, state, { visibilityFilter: action.filter });
default:
return state;
}
}
假定 Object.assign 要比用 Babel polyfill 天生的代码要慢一个数量级。如许的状况下，要将一个本不支撑 Object.assign 的浏览器优化到使它具有 ES2015 才能，会引起很严峻的机能题目。
这个例子同时也指出了转译的另一个瑕玷：转译天生的代码，要比直接用 ES2015+ 写的代码体积更大。在上面的例子中，源代码有 203 个字符（gzip 紧缩后有 176 字节），而转译天生的代码有 588 个字符（gzip 紧缩后有 367 字节）。代码大小是本来的两倍。下面来看关于 “JavaScript 异步迭代器”的一个例子：
async function* readLines(path) {
let file = await fileOpen(path);
try {
while (!file.EOF) {
yield await file.readLine();
}
} finally {
await file.close();
}
}
Babel 转译这段 187 个字符（gzip 紧缩后 150 字节），会天生一段有 2987 个字符（gzip 紧缩后 971 字节）的 ES5 代码，这还不包含再生器运转时须要加载的分外依靠：
"use strict";
var _asyncGenerator = function () { function AwaitValue(value) { this.value = value; } function AsyncGenerator(gen) { var front, back; function send(key, arg) { return new Promise(function (resolve, reject) { var request = { key: key, arg: arg, resolve: resolve, reject: reject, next: null }; if (back) { back = back.next = request; } else { front = back = request; resume(key, arg); } }); } function resume(key, arg) { try { var result = gen[key](arg); var value = result.value; if (value instanceof AwaitValue) { Promise.resolve(value.value).then(function (arg) { resume("next", arg); }, function (arg) { resume("throw", arg); }); } else { settle(result.done ? "return" : "normal", result.value); } } catch (err) { settle("throw", err); } } function settle(type, value) { switch (type) { case "return": front.resolve({ value: value, done: true }); break; case "throw": front.reject(value); break; default: front.resolve({ value: value, done: false }); break; } front = front.next; if (front) { resume(front.key, front.arg); } else { back = null; } } this._invoke = send; if (typeof gen.return !== "function") { this.return = undefined; } } if (typeof Symbol === "function" && Symbol.asyncIterator) { AsyncGenerator.prototype[Symbol.asyncIterator] = function () { return this; }; } AsyncGenerator.prototype.next = function (arg) { return this._invoke("next", arg); }; AsyncGenerator.prototype.throw = function (arg) { return this._invoke("throw", arg); }; AsyncGenerator.prototype.return = function (arg) { return this._invoke("return", arg); }; return { wrap: function wrap(fn) { return function () { return new AsyncGenerator(fn.apply(this, arguments)); }; }, await: function await(value) { return new AwaitValue(value); } }; }();
var readLines = function () {
var _ref = _asyncGenerator.wrap(regeneratorRuntime.mark(function _callee(path) {
var file;
return regeneratorRuntime.wrap(function _callee$(_context) {
while (1) {
switch (_context.prev = _context.next) {
case 0:
_context.next = 2;
return _asyncGenerator.await(fileOpen(path));
case 2:
file = _context.sent;
_context.prev = 3;
case 4:
if (file.EOF) {
_context.next = 11;
break;
}
_context.next = 7;
return _asyncGenerator.await(file.readLine());
case 7:
_context.next = 9;
return _context.sent;
case 9:
_context.next = 4;
break;
case 11:
_context.prev = 11;
_context.next = 14;
return _asyncGenerator.await(file.close());
case 14:
return _context.finish(11);
case 15:
case "end":
return _context.stop();
}
}
}, _callee, this, [[3,, 11, 15]]);
}));
return function readLines(_x) {
return _ref.apply(this, arguments);
};
}();
这段代码的大小是本来的 6.5 倍，也就是说增长了 650% （天生的 _asyncGenerator 函数也能够被同享，不过这依靠于你怎样打包你的代码。假如被同享的话，多个异步迭代器共用会分摊代码大小带来的本钱）。我们以为久远来看一向经由过程转译的体式格局来支撑 ES5 是不可行的，代码 size 的增添不单单议会使下载的时候变长，而且也会增添剖析和编译的开支。假如我们想要完整改良页面加载速率，和挪动互联网运用的反应速率（特别在手机装备上），那末肯定要勉励开辟者运用 ES2015+ 来开辟，而不是开辟完今后转译成 ES5。关于不支撑 ES2015 的旧浏览器，只要给它们完整转译今后的代码去执行了，而关于 VM 系统，上面所说的这个愿景也要求我们不断地提拔 ES2015 的机能。
评价要领
正如上面所说的，ES2015+ 本身的相对机能如今已不是症结了。当前的症结是起首肯定要确保 ES2015+ 的机能要比纯 ES5 高，第二更主要的是肯定要比用 Babel 转译今后的版本机能高。现在已有了一个由 Kevin Decker 开辟的 six-speed 项目，这个项目多多少少完成了我们的需求：ES2015 特征 vs 纯 ES5 vs 转译天生代码三者之间的比较。
因而我们如今把提拔相对机能作为我们做 ES2015+ 机能提拔的基本。起首将会把注意力聚焦于那些最严峻的题目上，即上面图中所列出的，从纯 ES5 所对应的 ES2015+ 版本机能下落 2 倍的那些项。之所以这么说是由于有个条件假定，假定纯 ES5 的版本最少会和响应 Babel 天生的版本速率一样快。
为当代言语而生的当代架构
之前版本的 V8 优化像 ES2015+ 如许的言语是比较难题的。比方想要加一个非常处置惩罚（即 try/chtch/finally）到 Crankshaft （V8 之前版本的优化编译器）是不能够的。就是说以 V8 的才能去优化 ES6 中的 for...of （这内里隐含有 finally 语句）都是有题目的。Crankshaft 在增添新的言语特征到编译器方面有很多局限性和完成的庞杂性，这就使得 V8 框架的更新优化速率很难跟得上 ES 标准化的速率。拖慢了 V8 生长的节拍。
荣幸的是，lgnition 和 TurboFan （V8 的新版诠释器和编译器）在设想之初就斟酌支撑全部 JavaScript 言语系统。包含先进的掌握流、非常处置惩罚、近来的 for...of 特征和 ES2015 的重构等。lgnition 和 TurboFan 的麋集组合架构使得关于新特征的团体优化和增量式优化成为能够。
很多我们已在当代言语特征上所获得的胜利只要在 lgnition/TurboFan 上才能够完成。 lgnition/TurboFan 在优化天生器和异步函数方面的设想特别症结。V8 一向以来都支撑天生器，然则由于 Crankshaft 的限定，对其优化会极为受限。新的编译器应用 lgnition 天生字节码，这能够使庞杂的天生器掌握流转化为简朴的当地字节掌握流。TurboFan 也能够更轻易完成基于字撙节的优化，由于它不要知道天生器掌握流的特别细节，只须要知道怎样保留和恢复函数声明就能够了。
联合声明
我们短时间目的是尽快完成少于 2 倍的机能改良。起首从最差状况的试验最先，从 Chrome M54 到 Chrome M58 我们胜利的把慢于 2 倍的测试集从 16 个降到了 8 个。同时也明显地使迟缓水平的中位数和均匀数得以下降。
从下图中我们能够清楚地看到变化趋向，已完成了均匀机能超过了 ES5 也许 47%，这里列出的是在 M54 上的一些典范数据。
别的我们明显提高了基于迭代的新言语的机能，比方通报操作符和 for...of 轮回等。下面是一个数组的重构状况：
function fn() {
var [c] = data;
return c;
}
比纯 ES5 版本还要快。ES5：
function fn() {
var c = data[0];
return c;
}
比 Babel 天生的代码要快的更多。Babel：
"use strict";
var _slicedToArray = function () { function sliceIterator(arr, i) { var _arr = []; var _n = true; var _d = false; var _e = undefined; try { for (var _i = arr[Symbol.iterator](), _s; !(_n = (_s = _i.next()).done); _n = true) { _arr.push(_s.value); if (i && _arr.length === i) break; } } catch (err) { _d = true; _e = err; } finally { try { if (!_n && _i["return"]) _i["return"](); } finally { if (_d) throw _e; } } return _arr; } return function (arr, i) { if (Array.isArray(arr)) { return arr; } else if (Symbol.iterator in Object(arr)) { return sliceIterator(arr, i); } else { throw new TypeError("Invalid attempt to destructure non-iterable instance"); } }; }();
function fn() {
var _data = data,
_data2 = _slicedToArray(_data, 1),
c = _data2[0];
return c;
}
你能够到“高速 ES2015” 来相识更多细节的信息。下面这里是我们在 2017 年 1 月 12 日发出的视频衔接。
我们会继承针对 ES2015+ 的特征提拔其机能。假如你对这一题目感兴趣，请看我们 V8 的“ES2015 and beyond performance plan。
假如人人对文章感兴趣，迎接关注我的知乎专栏-前端大哈。按期宣布高质量文章。
我近来正在写一本《React.js 小书》，对 React.js 感兴趣的童鞋，迎接指导。
