1
autoxbc 2018-06-28 12:08:35 +08:00 via iPhone
是的,意识到这个后,我把自己代码里所有的 reduce 都改写了,尤其是展开再合并那种
|
2
VDimos 2018-06-28 12:14:42 +08:00 via Android
不推荐使用 reduce
|
3
Torpedo 2018-06-28 12:36:29 +08:00 1
test1,test1.2,test1.3 到后来每次循环都是把一个 成百上千的对象的属性赋值给一个新的对象,能不慢么。。。
|
4
qdwang 2018-06-28 12:43:35 +08:00
reduce 实力背锅
|
5
jimliang 2018-06-28 13:11:43 +08:00
|
6
UnluckyNinja 2018-06-28 17:09:41 +08:00
吃饭的时候,
吃一口,把筷子洗了,洗双新筷子,然后吃下一口,再洗掉,再换新的, 感受一下 |
8
Pastsong 2018-06-28 17:31:51 +08:00
因为 reduce 是 immutable 的
|
9
iugo OP |
10
auroraccc 2018-06-28 17:58:13 +08:00
不是 reduce 的锅吧 , 主要是 ... 耗时
|
11
iugo OP 声明对象不可怕, 声明大对象是有点吓人.
对于标题, 我觉得结论可能是: 使用 Array.proto.reduce 的时候, 一定要复用 accumulator. |
12
UnluckyNinja 2018-06-28 18:09:13 +08:00
@iugo #9 testFn 根本就没用到 testAcc ……只是每次循环对其赋值,只是执行了 1000 对长度为 1 的对象添加了一个属性而已……(你添加属性的方法是返回新变量)
你之前那个脚本问题在于对对象,你循环 n 次,每次都要对第 n-1 次循环的返回对象打散然后重组,相当于操作 n-1 次 Object.assign。也就是复杂度大约为 O(n^2),当然慢啦…… |
13
morethansean 2018-06-28 18:58:26 +08:00
这么多写操作……
而且光是 GC 的时间就比你第二种操作耗时多好多倍了…… |
14
iugo OP 关于使用 reduce 的时候是否要修改 acc 问题, 我想这个 issue 是值得参考的: https://github.com/eslint/eslint/issues/8581
|