“锁定”的任何性能优势都可以通过“锁定”来实现。 JavaScript 对象？

Question

JavaScript 1.8.5 (ECMAScript 5) 添加了一些有趣的方法，以不同程度的彻底性防止将来修改所传递的对象：

• Object.preventExtensions(obj)
• Object.seal(obj)
• Object.freeze(obj)

大概是要点其中之一是捕获错误：如果您知道在某个点之后不想修改某个对象，则可以将其锁定，这样如果您以后无意中尝试修改它，就会抛出错误。 （前提是您已经完成了“use strict”；。）

我的问题：在现代 JS 引擎（例如 V8）中，是否有任何性能优势（例如，更快的属性）使用上述方法锁定对象时的查找、减少内存占用？

（另请参阅 John Resig 的精彩解释 – 没有提到性能，尽管。）

Answer 1

至少从 Chrome 47.0.2526.80（64 位）开始，性能没有差异。

Testing in Chrome 6.0.3359 on Mac OS 10.13.4
-----------------------------------------------
Test               Ops/sec
non-frozen object  106,825,468  ±1.08%  fastest
frozen object      106,176,323  ±1.04%  fastest

性能测试（可在 http://jsperf.com/performance-frozen-object 获取）：

  const o1 = {a: 1};
  const o2 = {a: 1};

  Object.freeze(o2);

  // Non-frozen object:
  for(var key in o1);

  // Frozen object:
  for(var key in o2);

< strong>更新 30.10.2019：Chrome 78.0.3904（64 位）上的性能没有差异

更新2019 年 9 月 17 日：Chrome 上的性能没有差异 76.0.3809（64 位）

2018 年 5 月 3 日更新：Chrome 上的性能没有差异< strong>66.0.3359（64 位）

更新 06.03.2017：没有区别Chrome 56.0.2924（64 位）

更新 13.12.2015 上的性能：Chrome 47.0.2526.80（64 位）上的性能没有差异-bit)

---

在 Chrome 34 中，在 @pimvdb 的测试用例中，冻结对象的性能略好于非冻结对象（结果如下）。然而，差异似乎不足以证明使用此技术来提高性能是合理的。

http://jsperf.com/performance-frozen-object

Testing in Chrome 34.0.1847.116 on OS X 10.9.2
----------------------------------------------
Test               Ops/sec
non-frozen object  105,250,353  ±0.41%  3% slower
frozen object      108,188,527  ±0.55%  fastest

运行 @kangax 的测试用例表明，对象版本的性能几乎相同：

http://jsperf.com/performance-frozen-object-prop-access

Testing in Chrome 34.0.1847.116 on OS X 10.9.2
----------------------------------------------
Test               Ops/sec
non-frozen object  832,133,923  ±0.26%  fastest
frozen object      832,501,726  ±0.28%  fastest

http://jsperf.com/http-jsperf-com-performance-frozen-object-instanceof

Testing in Chrome 34.0.1847.116 on OS X 10.9.2
----------------------------------------------
Test               Ops/sec
non-frozen object  378,464,917  ±0.42%  fastest
frozen object      378,705,082  ±0.24%  fastest

Answer 2

理论上，冻结对象可以让您对对象的形状做出更有力的保证。

这意味着虚拟机可以压缩内存大小。

这意味着虚拟机可以优化原型链中的属性查找。

这意味着任何活动引用都变得不活动，因为对象无法再更改。

实际上，JavaScript 引擎还没有进行这些激进的优化。

Answer 3

更新：由于此答案最初是编写的， V8 中导致此问题的错误已得到修复。有关详细信息，请参阅 Jan Molak 的回答。

---

在 Google Chrome（即 V8）中，冻结对象的迭代速度比常规对象慢 98%。

http://jsperf.com/performance-frozen-object

Test name*              ops/sec

non-frozen object    32,193,471
frozen object           592,726

可能是因为这些函数是相对较新，可能尚未优化（但这只是我的猜测，老实说我不知道​​原因）。

无论如何，我真的不建议使用它来提高性能，因为这显然没有意义。

---

* 测试代码为：

var o1 = {a: 1};
var o2 = {a: 1};

Object.freeze(o2);

测试 1（非冻结对象）：

for(var key in o1);

测试 2（冻结对象）：

for(var key in o2);

Answer 4

自 2013 年 6 月 20 日起，V8 已优化 Object.freeze。自 2014 年 12 月 10 日起，V8 已优化 Object.seal 和 Object.preventExtensions。请参阅问题 https://code.google.com/p/chromium/issues/detail?id=115960

Answer 5

答案中的 jsperf 链接已损坏，加上空的 for 循环可能会导致某些引擎中的死代码消除，因此我编写了一个新测试以确保不会发生代码消除。大多数情况下，冻结对象获胜：

perf.link benchmark

作为参考，代码如下所示：

const o1 = {a: 1};
const o2 = {a: 1};

Object.freeze(o2);

// store stuff to prevent any sort of theoretical dead code elimination
const buffer = [];

// test 1, unfrozen
for(const key in o1) buffer.push(key);

// test 2, frozen
for(const key in o2) buffer.push(key);

编辑：我试图进一步消除死代码消除的可能性。 也许（？）引擎可以检测并消除从未读取过的未使用的buffer数组，因此在下面的基准测试中，我将该对象放置在globalThis对象上，并且冻结对象往往会更频繁地获胜（已编辑，最近它更频繁地获胜，但在某些时候速度较慢）：

perf.link 基准测试

作为参考，代码如下：

const o1 = {a: 1};
const o2 = {a: 1};

Object.freeze(o2);

// store stuff to prevent any sort of theoretical dead code elimination
globalThis._buffer = [];

// test 1, unfrozen
for(const key in o1) globalThis._buffer.push(key);

// test 2, frozen
for(const key in o2) globalThis._buffer.push(key);

Answer 6

如果您对对象创建的性能感兴趣（文字、冻结、密封、Immutable.Map)，我创建了一个 测试jsPerf 来检查一下。

到目前为止，我只有机会在 Chrome 41 和 Firefox 37 中测试它。在这两种浏览器中，创建冻结或密封对象的时间比创建文字的时间大约三倍 - 而Immutable.Map 的性能比文字差大约 50 倍。

Answer 7

我在生产代码中看到这些方法的唯一原因是，出于完整性目的，您可以密封或冻结对象。

例如，我编写了一个小库，它运行得很好，并为您提供了对象中的一组方法，但我不希望您更改或覆盖我的任何属性或方法。我并不是说我可以阻止你这样做，但我可以尝试阻止你意外地这样做，这也许更重要。

此外，这些方法很容易在不了解它们的环境中进行“填充”，只需返回原始对象即可。当然那时候就没有什么影响了。

我没有看到任何与性能相关的原因这样做。