破坏变量性能

Question

写入之间是否存在性能差异(如果有的话)

const color = props.color;

与

const { color } = props;

---

此外，如果我们在参数签名中进行破坏，我们会获得或失去任何性能吗？参见示例3

我认为在这种情况下，示例3将是编写函数的最佳方式？

---

功能反应组件示例：

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>;
};

Answer 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中，析构函数赋值的计算效率低于传统函数参数。就内存空间利用率而言，答案有点复杂，可以在这里参考。

这可能是一个过早的优化，但在计算量大的代码中，建议考虑不使用析构函数赋值。

Answer 2

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

请注意，使用React，您的代码将被传输，这将与相同

const color = props.color

在babel编译器在线测试仪上检查结果

Answer 3

我也有同感。我想破坏会消耗更多的内存。当通过引用访问对象属性或数组元素时，我们访问的是相同的内存位置。当对象或数组被破坏时，如果值是基元，则这些值将被复制到新位置。因此，与通过对象属性进行访问相比，析构函数确实消耗了更多的内存。