解构变量性能答案

【问题标题】：Destructuring Variables Performance解构变量性能
【发布时间】：2018-04-16 09:45:09
【问题描述】：

写作之间是否存在性能差异（如果有）

const color = props.color;

对

const { color } = props;

另外，如果我们在参数签名中解构，我们会获得或失去任何性能吗？见例子3

我认为在这种情况下 example3 是编写函数的最佳方式？

示例功能性反应组件：

const example1 = (props) => {
  const color = props.color;
  // I know I could also just write style={{ color: props.color }}
  // but for arguments sake lets say I want to write it like this.
  return <h1 style={{ color }}>Hello</h1>;
};

const example2 = (props) => {
  const { color } = props;
  return <h1 style={{ color }}>Hello</h1>;
};

const example3 = ({ color }) => {
  return <h1 style={{ color }}>Hello</h1>;
};

【问题讨论】：

请记住，您使用的是 JSX，因此您的代码在运行之前会被转译，很可能所有这三个代码都会产生非常相似/相同的代码。
最好在大多数时间谷歌js perf {feature} 来获得答案...见jsperf.com/destructuring/5
一般答案是：“这取决于，可能更快或更慢或相同。但它极不太可能对现实世界产生影响；不用担心直到/除非您发现问题并发现它与 X 有关。” （其中 X 是您过早担心的事情）。
这类问题的答案总是一样的。在您现在关心的任何 Javascript 环境中测试自己。然后，不要假设测试结果适用于现在或一年后的任何其他 Javascript 环境。这些东西在每个环境中通常都是不同的，并且会随着时间而变化。如果您正在对特定环境中的性能声明进行微优化，则必须开发自己的测试以查看最适合您的方法。而且，在您花时间这样做之前，您应该向自己证明差异确实很重要。
这是您应该优化可读性而不是过早地对速度进行微优化的事情之一。

标签： javascript reactjs ecmascript-6 destructuring

【解决方案1】：

编译器/转译器不一定总是会删除解构分配，因为截至 2020 年所有常青浏览器都支持本机解构。根据，有证据表明，至少到 2018 年，V8 中通过解构分配生成的字节码比传统的函数参数要冗长得多：

函数参数：

function add(number1, number2){
  return number1 + number2;
}
const result = add(1,5);

输出字节码：

[generating bytecode for function: add]
Parameter count 3
Frame size 0
   74 E> 0x2a2a0affd2a2 @    0 : 91                StackCheck 
   96 S> 0x2a2a0affd2a3 @    1 : 1d 02             Ldar a1
  111 E> 0x2a2a0affd2a5 @    3 : 2b 03 00          Add a0, [0]
  121 S> 0x2a2a0affd2a8 @    6 : 95                Return 
Constant pool (size = 0)
Handler Table (size = 16)

解构赋值：

function add({number1, number2}){
  return number1 + number2;
}
const result = add({number1: 1, number2: 5});

输出字节码：

[generating bytecode for function: add]
Parameter count 2
Frame size 40
   74 E> 0x2c1d63b7d312 @    0 : 91                StackCheck 
         0x2c1d63b7d313 @    1 : 1f 02 fb          Mov a0, r0
         0x2c1d63b7d316 @    4 : 1d fb             Ldar r0
         0x2c1d63b7d318 @    6 : 89 06             JumpIfUndefined [6] (0x2c1d63b7d31e @ 12)
         0x2c1d63b7d31a @    8 : 1d fb             Ldar r0
         0x2c1d63b7d31c @   10 : 88 10             JumpIfNotNull [16] (0x2c1d63b7d32c @ 26)
         0x2c1d63b7d31e @   12 : 03 3f             LdaSmi [63]
         0x2c1d63b7d320 @   14 : 1e f8             Star r3
         0x2c1d63b7d322 @   16 : 09 00             LdaConstant [0]
         0x2c1d63b7d324 @   18 : 1e f7             Star r4
         0x2c1d63b7d326 @   20 : 53 e8 00 f8 02    CallRuntime [NewTypeError], r3-r4
   76 E> 0x2c1d63b7d32b @   25 : 93                Throw 
   76 S> 0x2c1d63b7d32c @   26 : 20 fb 00 02       LdaNamedProperty r0, [0], [2]
         0x2c1d63b7d330 @   30 : 1e fa             Star r1
   85 S> 0x2c1d63b7d332 @   32 : 20 fb 01 04       LdaNamedProperty r0, [1], [4]
         0x2c1d63b7d336 @   36 : 1e f9             Star r2
   98 S> 0x2c1d63b7d338 @   38 : 1d f9             Ldar r2
  113 E> 0x2c1d63b7d33a @   40 : 2b fa 06          Add r1, [6]
  123 S> 0x2c1d63b7d33d @   43 : 95                Return 
Constant pool (size = 2)
Handler Table (size = 16)

字节码行数显着增加，从函数参数的 4 行增加到解构赋值的 19 行。总之，截至 2018 年的 V8 中，解构赋值的计算效率低于传统函数参数。在内存空间利用率方面，答案有点复杂，可以参考here。

这可能是一个过早的优化，但是在计算繁重的代码中，最好考虑不使用解构赋值。

【讨论】：

常规 args 和解构点之间的性能差异是存在的，但是被比较的两个函数并不等同于 ops。 function add(opts){ const number1 = opts.number1; const number2 = opts.number2; return number1 + number2; } 将是比较
在 v8 8.4.371.19-node.18 中，它们最终相同，现在看起来更简洁了。
正是我正在寻找的解释。谢谢

【解决方案2】：

不会有任何性能问题，因为您的代码将被编译/缩小等等。

请注意，使用 React，您的代码将被转译，其作用与

const color = props.color

在babel compiler online tester上查看结果

【讨论】：

在 babel 编译器中显示两种语法的不同输出。这个答案不再有效吗？

【解决方案3】：

我也是这么想的。我想破坏会消耗更多的内存。通过引用访问对象属性或数组元素时，我们访问的是相同的内存位置。当对象或数组被解构时，如果值是原始值，the values are copied into a new location。因此，解构确实比通过对象属性访问消耗更多的内存。

【讨论】：