Будь-яка вигода від “блокування” об’єктів JavaScript?

Question 1

JavaScript 1.8.5 (ECMAScript 5) додає кілька цікавих методів, що запобігають майбутнім модифікаціям переданого об’єкта з різним ступенем ретельності:

Імовірно, головним пунктом їх є виявлення помилок: якщо ви знаєте, що не хочете модифікувати об'єкт після певної точки, ви можете заблокувати його, щоб помилка видала помилку, якщо ви ненавмисно спробуєте змінити її пізніше. (За умови, що ви це зробили "use strict";.)

Моє питання: у сучасних двигунах JS, таких як V8, чи є якісь переваги в продуктивності (наприклад, швидший пошук властивостей, зменшення обсягу пам’яті) при блокуванні об’єктів за допомогою вищезазначених методів?

(Див. Також приємне пояснення Джона Резіга - однак, не згадується про продуктивність.)

Question 2

У різниці в продуктивності не було різниці, оскільки принаймні 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);

Оновлення 30.10.2019 : Немає різниці в продуктивності Chrome 78.0.3904 (64-розрядна версія )

Оновлення 17.09.2019 : Немає різниці в продуктивності Chrome 76.0.3809 (64-розрядна версія )

Оновлення 03.05.2018 : Немає різниці в продуктивності Chrome 66.0.3359 (64-розрядна версія )

Оновлення 06.03.2017 : Немає різниці в продуктивності Chrome 56.0.2924 (64-розрядна версія )

Оновлення 13.12.2015 : Немає різниці в продуктивності Chrome 47.0.2526.80 (64-розрядна версія )

У 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

Question 3

Оновлення: Оскільки ця відповідь була написана спочатку, виправлена помилка у V8, яка спричинила цю проблему . Докладніше див. У відповіді Яна Молака .

У 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);

Question 4

Теоретично заморожування об'єкта дозволяє зробити більш чіткі гарантії щодо форми об'єкта.

Це означає, що віртуальна машина може ущільнити обсяг пам'яті.

Це означає, що ВМ може оптимізувати пошук властивостей у ланцюжку прототипів.

Це означає, що будь-які посилання в режимі реального часу просто стали не активними, оскільки об’єкт більше не може змінюватися.

На практиці двигуни JavaScript ще не роблять цієї агресивної оптимізації.

Question 5

V8 оптимізував Object.freeze станом на 20 червня 2013 р., А Object.seal та Object.preventExtensions - від 10 грудня 2014 р. Див. Випуск https://code.google.com/p/chromium/issues/detail?id= 115960

Question 6

Якщо ви зацікавлені в продуктивності створення об’єкта (буквальний проти замороженого проти запечатаного проти Immutable.Map), я створив тест на jsPerf щоб перевірити це.

Наразі я мав можливість протестувати його лише в Chrome 41 і Firefox 37. В обох браузерах створення замороженого або запечатаного об’єкта займає приблизно втричі більше часу, ніж створення літералу - тоді як ефективність Immutable.Mapвиконується приблизно в 50 разів гірше, ніж буквальний.

Question 7

Єдина причина, яку я бачу для цих методів у виробничому коді, полягає в тому, що ви можете запечатати або заморозити предмети для цілісності.

Наприклад, я пишу невеличку бібліотеку, яка чудово працює і пропонує вам набір методів в об'єкті, але я не хочу, щоб ви змінювали або перезаписували будь-які мої властивості чи методи. Я не кажу, що можу перешкодити вам зробити це, але я можу спробувати перешкодити вам зробити це випадково, що, можливо, важливіше.

Крім того, ці методи легко «обшити» в середовищі, яке про них не знає, просто повернувши оригінальний об’єкт. Звичайно, тоді це не мало би ефекту.

Я не бачу жодних причин, пов’язаних з продуктивністю, щоб це зробити.