你们这个插件有性能问题 请排查

[zhangenming]

https://www.zhihu.com/question/355526029
偶然发现的 最后定位到是这个插件的问题

console.time();
Array.from(Array(10000 * 100).fill())
console.timeEnd();

例如这样代码 没开启此插件前耗时5ms左右 开启后立马上升到170ms左右
稳定复现 chrome 78/79/80 恐怖如斯

[gdh1995]

测试了一下旧版本的，发现Chrome 71和以前，耗时都是200~400ms（我机器慢了点），和这个插件是否启用无关。从Chrome 72开始，没安装这个插件的时候确实耗时突变到了10~15ms，安装上则耗时仍然很长。#enable-javascript-harmony 和 #disable-javascript-harmony-shipping 这两个控制项对这个问题没有影响。

所以，我觉得是某处代码比较反模式，和V8的某种假设冲突了，造成回滚到普通模式，影响了执行速度。

补充：在扩展程序背景页里，也有这个问题，其他扩展里速度正常，这个扩展的背景页里执行很慢。

[gdh1995]

确认了是webpack用的polyfill的bug，

问题定位

造成性能问题的代码是在bundle/commons3.js里对Array.from的检测：

t.exports = function (t, n) {
  if (!n && !o)
    return !1;
  var r = !1;
  try {
    var i = [7],
    u = i[e]();
    u.next = function () {
      return {
        done: r = !0
      }
    },
    i[e] = function () {
      return u
    },
    t(i)
  } catch (t) {}
  return r
}

核心代码是i[e] = ...和u.next = ...这两句，其中e是Symbol.iterator。当这两行中任意一行执行时，V8会回退到某种慢速模式，而且对整个进程都有影响，所以测试的时候要关掉标签页再打开才能测出来正确结果。

相似问题

我在core-js库里找到了类似报告 zloirock/core-js#377 (comment) ，也是在反馈Array.from性能下降的问题，而且造成问题的点几乎一样。

解决思路

更新webpack应该能解决，不行的话就屏蔽掉Array.from的polyfill自己写。

一种不会触发性能损失的polyfill ：zloirock/core-js@9aed55e 使用{ ... }来代替[7]，避免修改一些关键的内置类型

补充： 看了看发现babel-polyfill和@babel/polyfill都是引用的core-js v2.x，但这个问题的修复只在core-js v3里。看起来还是只能写trick来绕过去了。

[lmk123]

划词翻译好几年没有更新依赖了，看来得大规模升级一下了

[lmk123]

新版本正在开发中，这次我连 babel 都没有用，所以是不会有这个问题了

[lmk123]

v7.0 已经开发完成，这个版本没有用到 babel，应该不会有这个性能问题了，所以这个问题先关闭。