Skip to content

Files

Latest commit

1517e86 · Aug 21, 2019

History

History
88 lines (49 loc) · 4.45 KB

022.精读《V8 引擎特性带来的的 JS 性能变化》.md

File metadata and controls

88 lines (49 loc) · 4.45 KB

本期精读的文章是:V8 引擎特性带来的的 JS 性能变化

1 引言

logo

定时刷新一下对 js 的三观,防止经验变成坑。(对 IE 等浏览器的三观需保持不变)

2 内容概要

try catch 对性能的影响忽略不计

try catch 非常有用,特别在 node 端更是一个常规操作。前端框架也越来越多采用了异常捕获的方式,结合 async await 让代码组织得更加优雅,详细可以看我的这篇博文 统一异常捕获。react mixins 也喜欢 try 住 render 方法,包括 16 版本自动 try 住了所有 render,try catch 可谓无处不在。

node 8 版本之后 try 内部函数性能损耗可以忽略不计。

但是当前版本仍然存在安全隐患,将 这里的代码 拷贝到 chrome 控制台,当前页面会进入无限死循环。

此例子对 try catch 块做了大量循环,官方说法是在某些代码组合情况下陷入无限优化循环。

解决 delete 性能问题

js 正在变得越来越简单,该 delete 的地方也不会犹豫是否写成 undefined,以提升性能为代价降低代码可读性了。

arguments 转数组性能已不是问题

在 node8.3 版本及以上,该使用拓展运算符获取参数,不但没有性能问题,可读性也大大提高,结合 ts 时也能得到类型支持。

bind 对性能影响可以忽略

但是在 react 中副作用仍需警惕。由于 ui 组件复用次数在大部分场景及其有限,强烈推荐使用箭头函数书写成员函数(在我的另一篇精读 This 带来的困惑 有详细介绍),而且在 node8 中,箭头函数的性能是最好的。

函数调用对性能影响越来越小

对函数调用优化的越来越好,不需要过于担心注释与空白、函数间调用对性能的影响.

32 64 位数字计算性能

node8 对超长数字计算性能还是较低,大概是 32 位数字性能的 2/3,所以尽量用字符串处理大数。

遍历 object

基本用法有 for in Object.keys Object.values. 在 node8 中,for in 将变得更慢,但任然比其他两种方法快,所以,尽早取消不必要的优化。

创建对象

创建对象速度在 node8 得到极大提升,似乎是面向对象编程的福音。

多态函数的性能问题

当函数或者对象存在多种类型参数时,在 node8 中性能没什么优化,但单态函数性能大幅提升。所以尽量让对象内部属性单态是比较有用的,比如尽量不要对字符串数组 push 一个数字。

3 精读

try catch 的问题

在 v8 优化之前,前端 try catch 存在挺大的性能问题,导致许多老旧的项目很少有使用异常的场景,而经验丰富的程序员也会极力避免使用 try catch,在必须使用 try catch 的地方,将代码逻辑封装在函数中,try 住函数而不是代码块,以降低性能损失。

现在是推翻这些经验的时候了,合理的异常处理还能够优化用户体验。

前端代码最容易出错的逻辑在于对后端数据的处理,一旦后端数据出错,前端整条数据处理链路难免报错或者抛出异常。这种场景最适合将异常 try 住,显示提示文案,同时也避免代码内部对数据格式过多的兼容处理。

语句数量对性能的影响

由于语句数量对性能影响已经忽略不计了,以前推崇的写法可以说再见了:

// 提倡
var i = 1;
var j = "hello";
var arr = [1,2,3];
var now = new Date();
 
// 避免
var i = 1,
    j = "hello",
    arr = [1,2,3],
    now = new Date();

4 总结

这波 v8 优化带来了一些 js 性能上的改变,但在 js 性能优化中只解决了很小一块问题,而 js 在前端性能优化又只是冰山一角,dom 与 样式 的优化对性能影响也非常重大,我们仍然应该重视代码质量,提高代码性能。

讨论地址是:精读《V8 引擎特性带来的的 JS 性能变化》 · Issue #33 · dt-fe/weekly

如果你想参与讨论,请点击这里,每周都有新的主题,每周五发布。