javascript - 为什么我应该避免在 shouldComponentUpdate 中使用 _.isEqual

Question

我已经多次阅读这个问题，每次建议的答案都是不要使用深度比较，因为它的成本很高。我尝试在我的应用程序中实现这一点，它看起来确实非常快。

  shouldComponentUpdate = (nextProps, nextState) => {
    let a = +new Date();
    let equalProps = _.isEqual(this.props, nextProps);
    let equalState = _.isEqual(this.state, nextState);
    let b = +new Date();
    console.log("----> deep equality navbar took ", b - a, " result = ", equalProps && equalState);

    if (equalProps && equalState) return false;

    return true;
  };

这是生成的日志示例:

----> deep equality msg list took  0  result =  false
----> deep equality msg list took  0  result =  false
----> deep equality navbar took  0  result =  true
----> deep equality sidebar took  0  result =  true
----> deep equality msg list took  1  result =  false

基本上，它似乎永远不会超过 1 毫秒，而且我正在处理一些 6/7 层的嵌套对象。消息列表的渲染通常需要超过 70 毫秒。我可以通过不到 1 毫秒的函数调用轻松避免。

我在这里错过了一些大事吗？这似乎几乎是真的……烤我:)

Answer 1

这是因为您使用的是小样本数据，所以您没有发现任何速度问题，如果有大数据可供比较，那么这将是一个大问题，因为 componentshouldupdate 在每个状态更新上运行，所以如果 lodash.isEqual需要一些时间，它会减慢 react 页面渲染速度

您可以在下面看到一个对象列表，比较并找到您项目的更好的对象

fast-deep-equal x 226,960 ops/sec ±1.55% (86 runs sampled)
nano-equal x 218,210 ops/sec ±0.79% (89 runs sampled)
shallow-equal-fuzzy x 206,762 ops/sec ±0.84% (88 runs sampled)
underscore.isEqual x 128,668 ops/sec ±0.75% (91 runs sampled)
lodash.isEqual x 44,895 ops/sec ±0.67% (85 runs sampled)
deep-equal x 51,616 ops/sec ±0.96% (90 runs sampled)
deep-eql x 28,218 ops/sec ±0.42% (85 runs sampled)
assert.deepStrictEqual x 1,777 ops/sec ±1.05% (86 runs sampled)
ramda.equals x 13,466 ops/sec ±0.82% (86 runs sampled)
The fastest is fast-deep-equal

https://github.com/epoberezkin/fast-deep-equal