阅读 902

JS数组性能小则|你以为的快不是真的快

场景

这是在写一个特殊的 React 业务组件(虚拟树形列表)时想到的一个问题,当时我内部实现了一个继承数组的类(因为不想用 Getter 的方式去访问这个类存储的数据,所以选择直接继承数组,这样也可以在内部直接用 this 去访问数组本身以及方法)并且要实现一个内部过滤数据并且可以重置过滤的功能。

我第一时间想到的便是,在初始化时给每个数据打上标记,过滤时把数据取出,重置时把数据放回并且按标记来重新排序。

class DataArr extends Array {
    constructor(data, key){
        super()
        this.dataMap = {}
        this.dataKey = key
        this.dataWhichBeFiltered = []
    }
    initData () {
        this.forEach((item, index) => {
            this.initItem(item, {
                index
            })
        })
    }
    initItem (item, opt) {
        this.dataMap[item[this.dataKey]] = item
        item._index = opt.index
    }
    filter () {}
    resetFilter () {}
}

// usage
const data = new DataArr(arr)

data.filter(item => item.a === 1)
data.resetFilter()

复制代码

然后问题就来了,在这种情况下 filter 我们不能直接用 Array.prototype.filter,因为这个方法只会返回新数组,我们没办法写 this = this.filter(item => item.a === 1) 这样的代码。

过程

写一个数组自己 filter 的方法,我一开始就想到数组倒序遍历然后在当中用 splice 一个一个把要摘的数据提出来,就像下面这样

filter (fn) {
    for (let i = this.length - 1; i >= 0 ;i--) {
        const item = this[i]
        if (!!fn(item)) {
            const delItem = this.splice(i, 1)[0]
            this.dataWhichBeFiltered.push(delItem)
        }
    }
}
复制代码

这样执行的结果确实可行,但却有着不低的隐患,至今很多人以为 splicepoppush 这些方法一样,是很常规的 O(1) 操作,实际上 splice 的性能是非常差的。我问我的前端同事小伙伴,他们也觉得没有多大的问题,而我有时候在逛掘金的时候也碰见过 “倒序遍历 splice 真的很爽” 这样的评论。

除了上面的方式,我还想了一个看起来慢,但实际上比循环 splice 快将近 100 倍的方案,就是循环标记需要过滤的内容,而后将要过滤的内容排序到末尾再将他们切除。

filter (fn) {
    let index = 0
    for (let i = this.length - 1; i >= 0 ;i--) {
        const item = this[i]
        if (!!fn(item)) {
            item.willBeFiltered = 1
            index ++
        }
        else item.willBeFiltered = 0
    }
    this.sort((a, b) => b.willBeFiltered - a.willBeFiltered)
    this.dataWhichBeFiltered = this.splice(i)
}
复制代码

在浏览器 console 中测试的结果图

直接倒序遍历 splice

image.png

先排序后 splice,1w 的数据量不算多,但是占用 1s 以上已经有严重的卡顿感了。

image.png

原由

splice 的缓慢在于数组的插入移除操作不像链表,只需要切除要移除的节点,再把 prev 节点和 next 节点连接就完成了。

数组中的元素存在一个连续的内存块中并且只能用索引访问。

也就是说数组的存放是有先后顺序的,用数组下标去访问每一个数组元素,当我们“简单”地在数组当中移除掉或者插入一个或者多个数组元素,那么需要对应地改变这个元素之后地所有元素的下标,这样的行为带来了不少的损耗。

原数组 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

移除当中的元素 【5】 arr.splice(4,1) [1, 2, 3, 4, 6, 7, 8, 9, 10]

数组的变化(移除前-移除后)
0 => 1          0 => 1
1 => 2          1 => 2
2 => 3          2 => 3
3 => 4          3 => 4
4 => 5    =>    4 => 6
5 => 6    =>    5 => 7
6 => 7    =>    6 => 8
7 => 8    =>    7 => 9
8 => 9    =>    8 => 10
9 => 10         
复制代码

这个变化带来的影响与数组长度以及需要调整的下标数量有关。除了 splice 还有一个具有同样性能损耗的,就是同样具有插入功能的 unshift 方法了。

tips

除了上面的问题,我还发现一个不经意的一个 es6 带来的变化。上面说到,除了实现 filter 功能还要实现一个 resetFilter,这个方法说来也简单,就是把 dataWhichBeFiltered 的数据重新加回数组,然后我们在按原 index 排序就阔以了。

    this.dataWhichBeFiltered.forEach(data => this.push(data))
    this.sort((a, b) => a._index - b._index)
复制代码

这时候同样的我也不能写 this = this.concat(this.dataWhichBeFiltered),只能循环一个一个地 push 回原数组。

但我当时随手试了一下 push 方法,原来 push 是可以传多个参数的!

arr.push(element1, ..., elementN)

因为在以前 es5 的环境下很少会用 push 传多个参数去新增多项数组项(因为你不能动态的往 push 方法里传参),但是现在由于 es6 新加入的拓展运算符,我们可以直接就是 this.push(...this.beFilteredData)。效果无论是从哪方面看都非常让我满意。而在以前的代码里还躺着 const result = arr1.concat(arr2) 这样的过去式代码。

总结

总结一下,在前端浏览器环境中,没四千万不要在数组循环中使用 splice 或者 unshift 方法,在数据量超过一定数量时,这样操作会耗费大量性能。因为数组的元素是存在一块连续的内存块中,只能通过索引访问,当发生删除或者插入操作时,会引起当中一系列连锁变化,导致性能变差。

我想起某位知名大佬写的快排,当中循环的一个 splice 直接把"快"排变成了"慢"排。导致被各路大神疯狂吐槽,这也是很久之前的事情了。现在人家都是人生赢家了,而我还在办公室里加班QAQ。


Hello 这里是 Roxz, 欢迎给我的文章点赞~我会在精神上默默感谢你的鼓励。

文章分类
前端
文章标签